Bug Tracker

Opened 6 years ago

Closed 6 years ago

Last modified 5 years ago

#8763 closed bug (fixed)

Unhandled exception: document.defaultView.getComputedStyle(div, null) is null (FF, hidden iframe)

Reported by: Đonny Owned by: Rick Waldron
Priority: blocker Milestone: 1.6.1
Component: support Version: 1.5.2
Keywords: regression Cc:
Blocked by: Blocking:


When there is jQuery in iframe which is hidden follwing error occurs in Firefox 4: Error: document.defaultView.getComputedStyle(div, null) is null Source: jquery.js Line: 1286 It works fine in Chrome and IE8.

This is probably related to http://bugs.jquery.com/ticket/8635.

How to replicate:

see sample here: http://dzonny.cz/misc/jQueryBug/main.htm


--- main.html ---

<div style="display:none">
    <iframe src="iframe.htm" width="601" height="601"></iframe>

--- iframe.html ---

    <script src="jquery.debug.js" type="text/javascript"></script>
    <script type="text/javascript">
        $(document).ready(function () {
            alert('I\'m ready!');

Environment: FF4x86, Windows 7 x64

Symptoms: Error in FF JS console, alert not shown

Expected behavior: No error, alert is shown

Change History (20)

comment:1 Changed 6 years ago by Rick Waldron

Component: unfiledsupport
Keywords: regression added
Priority: undecidedblocker
Resolution: worksforme
Status: newclosed

Does not exist with most recent build


comment:2 Changed 6 years ago by bdevel

I'm getting this issue as well. It works in the jsfiddle but the URL Donny posted does reproduce the issue on my machine.

Firefox/3.6.16 - Intel Mac OS X 10.6

Error: document.defaultView.getComputedStyle(div, null) is null Source File: /misc/jQueryBug/jquery.debug.js Line: 1286

jQuery.support.reliableMarginRight = ( parseInt(document.defaultView.getComputedStyle(div, null).marginRight, 10)
0 ) === 0;

comment:3 Changed 6 years ago by Rick Waldron

Resolution: worksforme
Status: closedreopened

comment:4 Changed 6 years ago by Rick Waldron

Owner: set to Rick Waldron
Status: reopenedassigned

comment:5 Changed 6 years ago by anonymous

I have the same problem here. is there a hack somewhere to make it work ?

comment:6 Changed 6 years ago by willy.schott@…

I was able to reproduce the problem in a very specific setting: when sending a post request to an <iframe style="display:none"> (file upload), the jQuery instance inside the IFrame raises that error. A solution for that particular case is hiding the iframe by other means, i.e. negative offsets.

comment:7 Changed 6 years ago by ph@…

I ran into this bug independently and narrowed it down to a minimal testcase: http://malaprop.org/jq/outer.html http://malaprop.org/jq/inner.html

#jquery-dev helped me make a copy of it on jsfiddle: http://jsfiddle.net/gnarf/sBbVC/3/

Last edited 6 years ago by gnarf (previous) (diff)

comment:8 Changed 6 years ago by ph@…

Also, I don't think this bug is related to #8635, it happens with 1.5.1, too.

comment:9 Changed 6 years ago by Rick Waldron

#8783 is a duplicate of this ticket.

comment:10 Changed 6 years ago by Rick Waldron

Resolution: cantfix
Status: assignedclosed

This is an issue I ran into while working on the default display bug. Firefox will not render "presentation" (ie. computed styles) in iframes that are display:none or are inheriting display:none.

This is a bug in Firefox, not jQuery. If it's really necessary, I will provide the IRC chat transcript with the Mozilla employee that confirmed the issue.

comment:11 Changed 6 years ago by Đonny

Can at least some workaround be implemented, so exception is not thrown? Like

if(document.defaultView.getComputedStyle(div, null) === null) return null;

jQuery is well-known to work despite bugs in browsers.
Do you know if Mozilla is going to fix it any soon?

comment:12 Changed 6 years ago by Rick Waldron

I'll give it a run through test with all of our supported browsers, just to humour your suggestion, but the problem is that the issue cannot be fixed correctly without a lot of ugly code hacks... checking if display:none, storing that value, changing to block, getting the width/height, storing those values, setting width/height to 0 to hopefully ensure that it doesn't flash, getting the computed style you want and storing that value, restoring the previous width/height, restoring display:none ... how many DOM reflows is that?

Your suggestion is just NOT return something useful if we can infer an problem with doing so, which means that your code will work in other browsers and not in Firefox.

Please understand that I am sympathetic to your situation.

Last edited 6 years ago by Rick Waldron (previous) (diff)

comment:13 Changed 6 years ago by giskard22

I was running into this too when inserting content into hidden iframes. I modified the line in the jQuery source to make sure the style object exists before attempting to get one of its properties:

jQuery.support.reliableMarginRight = document.defaultView.getComputedStyle(div, null) ? ( parseInt(document.defaultView.getComputedStyle(div, null).marginRight, 10) || 0 ) === 0 : false;

I don't know if this is better than Donny's suggestion, but I think it sets reliableMarginRight to false if the browser can't prove it should be true.

comment:14 Changed 6 years ago by fredrik@…

I just upgraded to 1.6 but will now immediately downgrade to 1.4 since this bug doesn't seem to be fixed. All my uploads/interactive stuff runs in iFrames - and living without jQuery in these frames is a no can do - A real showstopper. I will retry upgrade in a month or so.

Thanks anyway! jQuery is a great layer of abstraction!

comment:15 Changed 6 years ago by dmethvin

#9054 is a duplicate of this ticket.

comment:16 Changed 6 years ago by dmethvin

Resolution: cantfix
Status: closedreopened

comment:17 Changed 6 years ago by dmethvin

Milestone: 1.next1.6.1

comment:18 Changed 6 years ago by dmethvin

Status: reopenedopen

comment:19 Changed 6 years ago by Sahab Yazdani

Resolution: fixed
Status: openclosed

comment:20 Changed 5 years ago by alexis@…

Just ran in this problem with 1.5.2. I see that my fix is the same as giskard22 and with it everything works as expected. So I can confirm that this is a good fix.

Note: See TracTickets for help on using tickets.