Closed Bug 795520 Opened 12 years ago Closed 12 years ago

getComputedStyle returns null inside IFRAME that has no CSS box yet due to lazy restyle processing


(Core :: DOM: CSS Object Model, defect)

15 Branch
Not set





(Reporter: aochider, Assigned: bzbarsky)



(3 files, 2 obsolete files)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20100101 Firefox/15.0.1
Build ID: 20120905151427

Steps to reproduce:

The src of an IFRAME has a script that uses the "getComputedStyle" method on an element inside itself. The IFRAME element is itself surrounded by an element that renders it display:none.

Actual results:

The "getComputedStyle" method returns null.

Expected results:

The "getComputedStyle" method returns a hashtable of computed styles.
Could you attach a testcase, please.
Attached file Index page (obsolete) —
Attached file IFRAME page (obsolete) —
Attached file Index page updated
Attachment #666239 - Attachment is obsolete: true
Attached file IFRAME page updated
Attachment #666240 - Attachment is obsolete: true
Attachment #666241 - Attachment mime type: text/plain → text/html
Attachment #666242 - Attachment mime type: text/plain → text/html
This is still an issue in 16
There is no sane way to compute style in a display:none iframe, because styles depend on the size of the frame due to media queries and the frame has no defines size. So anything we actually returned would be a lie that would have no bearing on reality.

There are existing reports about this, for what it's worth....
Whiteboard: DUPEME
Summary: getComputedStyle inside IFRAME → getComputedStyle returns null inside IFRAME that has no CSS box
Thank you for the explanation.

But why does Chrome not have this same issue?
Because it just makes up something that has no bearing on reality and returns it.  That happened to be easy to do in their implementation, so they did.
Haha, okay, thanks.

I understand the logical problem, but I wanted to file a bug because it can break jQuery's animation methods (which I happen to have to work with at work :( ).
Is this the case when you set display:none on the body and then jQuery's determination of default styles breaks?
Yes, kind of. It is more like this:

1)IFRAME hidden via parent element's class
2)User triggers event somehow
3)IFRAME parent's class removed
4)jQuery animation starts
5)jQuery tries to getComputedStyle but fails
6)Bug is filed at work :(

I did some tests and found that getComputedStyle does not take effect until a little bit after the parent's class has been removed.
>3)IFRAME parent's class removed
>5)jQuery tries to getComputedStyle but fails

Ah.  _That_ is eminently fixable!  That part of the testcase was sadly commented out...
Component: Untriaged → DOM: CSS Object Model
Ever confirmed: true
Product: Firefox → Core
Summary: getComputedStyle returns null inside IFRAME that has no CSS box → getComputedStyle returns null inside IFRAME that has no CSS box yet due to lazy restyle processing
Assignee: nobody → bzbarsky
Whiteboard: DUPEME
Cool, thanks!
from getComputedStyle, even if we have no presshell, then just throw
(after flushing, as needed) if people try to get style info for it
just like we already do for declarations whose document loses a
presshell.  This might cause compat issues on sites that can deal with
null but not exceptions, though.  :(
Attachment #670841 - Flags: review?(dbaron)
Whiteboard: [need review]
Comment on attachment 670841 [details] [diff] [review]
Don't fail to return a computed CSS declaration just because the style change that will give us a presshell has not been processed yet.   more risky, option would be to always return a declaration

Attachment #670841 - Flags: review?(dbaron) → review+
Flags: in-testsuite+
Whiteboard: [need review]
Target Milestone: --- → mozilla19
Closed: 12 years ago
Resolution: --- → FIXED
I don't believe this is fixed. I'm still able to replicate this (Running 43.0a1 (2015-09-07)). It also looks like this bug was referenced and implied that it wasn't fixed back in 2013
The bug as described in the summary is fixed.

The link you mention is talking about a situation in which an iframe is actually display:none all along, not just transiently missing a CSS box.  That's a different issue.
And in particular is covered by bug 548397 and bug 1012413.
That is quite possibly correct. It looks like they were linking the wrong bug in that discussion. I've CC'd myself to the other ones you've mentioned. Thanks.
You need to log in before you can comment on or make changes to this bug.