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

Status: RESOLVED FIXED

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

Description

[Andrew Tran]

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.

Comment 1

[Loic]

Could you attach a testcase, please.

Comment 2

[Andrew Tran]

Attachment: Index page

Comment 3

[Andrew Tran]

Attachment: IFRAME page

Comment 4

[Andrew Tran]

Attachment: Index page updated

Comment 5

[Andrew Tran]

Attachment: IFRAME page updated

Comment 6

[Andrew Tran]

This is still an issue in 16

Comment 7

[Boris Zbarsky [:bzbarsky]]

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....

Comment 8

[Andrew Tran]

Thank you for the explanation.

But why does Chrome not have this same issue?

Comment 9

[Boris Zbarsky [:bzbarsky]]

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.

Comment 10

[Andrew Tran]

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 :( ).

Comment 11

[Boris Zbarsky [:bzbarsky]]

Is this the case when you set display:none on the body and then jQuery's determination of default styles breaks?

Comment 12

[Andrew Tran]

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.

Comment 13

[Boris Zbarsky [:bzbarsky]]

>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...

Comment 14

[Andrew Tran]

Cool, thanks!

Comment 15

[Boris Zbarsky [:bzbarsky]]

Attachment: 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

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.  :(

Comment 16

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

Comment 17

[Boris Zbarsky [:bzbarsky]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/e711e4cdb4d5

Comment 18

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/e711e4cdb4d5

Comment 19

[Nathaniel van Diepen [:Eeems]]

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

Comment 20

[Boris Zbarsky [:bzbarsky]]

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.

Comment 21

[Boris Zbarsky [:bzbarsky]]

And in particular is covered by bug 548397 and bug 1012413.

Comment 22

[Nathaniel van Diepen [:Eeems]]

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.