Bug Tracker

Ticket #8763 (closed bug: fixed)

Opened 4 years ago

Last modified 2 years ago

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

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

Description

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

or

--- main.html ---

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

--- iframe.html ---

...
<head>
    <title>Iframe</title>
    <script src="jquery.debug.js" type="text/javascript"></script>
</head>
<body>
    <h2>Iframe</h2>
    <script type="text/javascript">
        //<![CDATA[
        $(document).ready(function () {
            alert('I\'m ready!');
        });
        //]]>
    </script>
</body>
...

Environment: FF4x86, Windows 7 x64

Symptoms: Error in FF JS console, alert not shown

Expected behavior: No error, alert is shown

Change History

comment:1 Changed 4 years ago by rwaldron

  • Keywords regression added
  • Priority changed from undecided to blocker
  • Status changed from new to closed
  • Component changed from unfiled to support
  • Resolution set to worksforme

Does not exist with most recent build

 http://jsfiddle.net/rwaldron/2heBa/

comment:2 Changed 4 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 4 years ago by rwaldron

  • Status changed from closed to reopened
  • Resolution worksforme deleted

comment:4 Changed 4 years ago by rwaldron

  • Owner set to rwaldron
  • Status changed from reopened to assigned

comment:5 Changed 4 years ago by anonymous

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

comment:6 Changed 4 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 4 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 4 years ago by gnarf (previous) (diff)

comment:8 Changed 4 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 3 years ago by rwaldron

#8783 is a duplicate of this ticket.

comment:10 Changed 3 years ago by rwaldron

  • Status changed from assigned to closed
  • Resolution set to cantfix

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 3 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 3 years ago by rwaldron

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 3 years ago by rwaldron (previous) (diff)

comment:13 Changed 3 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 3 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 3 years ago by dmethvin

#9054 is a duplicate of this ticket.

comment:16 Changed 3 years ago by dmethvin

  • Status changed from closed to reopened
  • Resolution cantfix deleted

comment:17 Changed 3 years ago by dmethvin

  • Milestone changed from 1.next to 1.6.1

comment:18 Changed 3 years ago by dmethvin

  • Status changed from reopened to open

comment:19 Changed 3 years ago by Sahab Yazdani

  • Status changed from open to closed
  • Resolution set to fixed

comment:20 Changed 2 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.