Closed Bug 795520 Opened 10 years ago Closed 9 years ago
Computed Style returns null inside IFRAME that has no CSS box yet due to lazy restyle processing
300 bytes, text/html
514 bytes, text/html
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
3.66 KB, patch
|Details | Diff | Splinter Review|
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.
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....
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...
Status: UNCONFIRMED → NEW
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
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)
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 r=dbaron
Attachment #670841 - Flags: review?(dbaron) → review+
Whiteboard: [need review]
Target Milestone: --- → mozilla19
Status: NEW → RESOLVED
Closed: 9 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 https://www.sencha.com/forum/showthread.php?276869-RightMargin-test-fails-in-Ext.supports&s=86665e3075360b34b20f01d183f38d61
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.
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.