View Full Version : [OPEN] RightMargin test fails in Ext.supports

26 Nov 2013, 11:40 PM
We were forced to patch ext-all.js (and ext-dev.js) due to a test failing in Ext.supports in one of our production environments, and there was no other way to patch it, since it fails on load. It is the test for RightMargin. I have replaced it with the following code:

identity: 'RightMargin',
fn: function(doc, div) {
view = doc.defaultView,
style = view.getComputedStyle(div.firstChild.firstChild, null)
return !(view && style && style.marginRight != '0px');

view.getComputedStyle(div.firstChild.firstChild, null) comes up undefined in the offending environment.

27 Nov 2013, 12:01 AM
Using which Ext version? In what browsers?

This code has been in the library for quite some time & I've not seen anyone have an issue with it. How can I reproduce it?

27 Nov 2013, 11:47 AM
It's in ExtJS 4.0.5 (though that code has not changed in 4.2.2) and is happening in Firefox within a Salesforce IFrame. That's all I know, as I'm not the one who encountered the problem.

27 Nov 2013, 12:47 PM
As you've said, that code has been there for quite some time and it gets run every time the framework spins up. It's fairly unlikely there's a bug there.

Also, some of the code surrounding how the tests are run is slightly different in newer versions.

It's also possible that the user environment could have something to do with it, the frame may be injecting something in a weird spot, or a browser plugin is having some impact.

Without a test case it's too nebulous to be able to call it a bug.

2 Dec 2013, 10:51 AM
When ExtJS is loaded within a SalesForce frame, this test fails. The call to view.getComputedStyle(div.firstChild.firstChild, null) returns null.
This appears to be because the iframe is initially hidden (display: none), so doc.defaultView is returning a reference to the wrong frame. This also fails in IE8, as IE8 does not understand getComputedStyle, so I'm surprised this hasn't been caught before.

2 Dec 2013, 12:20 PM
I have the exact same issue.
Occurs in the two FF browsers I have 3.5.1 and 19.
I will try to put together a example if I get some time, but here is a high level explanation.

Inside an EXTJS 2.3 app I launch a new Window with an iframe in it.
Inside the iframe I have an extjs 4.1.1 application.
Everything works ok.

Inside the same EXTJS 2.3 application I have a tabpanel, one of the tabs is an iframepanel (nothing but a box component with an iframe in it), and in the iframe I load the same EXTJS 4.1.1 app. The tab with the iframe is not the activetab and the tabpanel has deferredRender: false.
In Chrome, IE8, Safari, all is ok. In FF 3.5.1 and FF19 I get this error from within the iframe extjs 4.1.1:

identity: 'RightMargin',
fn: function(doc, div) {
var view = doc.defaultView;
return !(view && view.getComputedStyle(div.firstChild.firstChild, null).marginRight != '0px');

view.getComputedStyle(div.firstChild.firstChild, null) is undefined.

2 Dec 2013, 3:02 PM
It looks like in IE8 there are two issues:

doc.defaultView returns undefined
getComputedStyle does not exist (undefined), even if you have a window reference.

But in other browsers, if the frame in which ExtJS is loaded is hidden, doc.defaultView returns a reference to the wrong window object.

3 Dec 2013, 2:04 PM
Nice. This thread says it doesn't have enough information for a bug report, then presents a dead link.

Here's the information for the bug report:

Create a page with an iframe on it, with display: none in the style to hide it.
Load a page into the iframe that contains ExtJS.
Open the page in FireFox (for example).
Watch it fail.

getComputedStyle returns null because the iframe is hidden, so an attempt to reference the marginRight property on the null object will fail. Simple as that. Please fix.

3 Dec 2013, 5:51 PM
It's a fairly well known FF bug, you didn't initially say anything about IFrames so I didn't twig.


In this case, the thing that it's feature detecting only occurs on WebKit, so I think we can safely add a fix for it. If not, the issue would be you couldn't tell the difference between having no error or not being able to detect it.

An easy workaround for now would be to add visiblity: hidden and position it off screen with position: absolute;

Also, in the latest versions the supports are pre-computed for old IE to speed up loading times. They're a stable target now so there;s no point redoing them over & over, so there shouldn't be any issue in IE8.

4 Dec 2013, 11:58 AM
Thanks. I would agree that would be an easy workaround, if we had control over the container. But as I mentioned in an earlier post, it is loaded in a SalesForce IFrame, which is initially hidden (display: none) until it loads content, then makes it visible. :(