1109033 - getComputedStyle() on an element in an iframe may return old values after changed the style of that element

Status: NEW

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

Description

[Duan Yao]

Attachment: getComputedStyle-delay-iframe.html

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:35.0) Gecko/20100101 Firefox/35.0
Build ID: 20141201162954

Steps to reproduce:

Suppose el is an element in an iframe, and its width is 300px. In parent doc's JS context run these codes:

    var st = getComputedStyle(el);
    console.log(st.width); // '300px', expected
    el.style.width = '150px';
    console.log(st.width); // still '300px', not '150px' !?

Width the attachment you can test this issue with left, width and box-shadow properties. An interesting thing is that if you read ComputedStyle ~30ms after modified the element's style, it will return the new value.

This issue doesn't happen if you call "el.ownerDocument.defaultView.getComputedStyle(el)" instead of "getComputedStyle(el)".



Actual results:

Immediately after modified the element's style, the ComputedStyle returns old values.


Expected results:

Immediately after modified the element's style, the ComputedStyle should return new values.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Per spec, the CSS rules that apply in this case are the ones in the parent document, not the child.  So we don't flush layout in the child, since its rules are not supposed to affect the result.  The fact that waiting for 30ms starts returning 150px is probably a bug, but the spec is not very clear on the interaction of used values with the fact that you're supposed to use the rules of the document whose window getComputedStyle was called on.  I raised a spec issue at http://lists.w3.org/Archives/Public/www-style/2014Dec/0135.html

> This issue doesn't happen if you call
> "el.ownerDocument.defaultView.getComputedStyle(el)" 

Right, because then the style rules of el.ownerDocument are used.

Comment 2

[Duan Yao]

>Per spec, the CSS rules that apply in this case are the ones in the parent document, not the child.  So we don't flush layout in the child, since its rules are not supposed to affect the result.

What if the element in the child doc has a style attribute (this is a case in the attachment)? I thought it should be applied, no?

Comment 3

[Boris Zbarsky [:bzbarsky]]

Per spec as currently written, unclear.  And browsers may or may not match the spec very well in this case...

Comment 4

[Boris Zbarsky [:bzbarsky]]

Raised _that_ spec issue: http://lists.w3.org/Archives/Public/www-style/2014Dec/0137.html

Comment 5

[Duan Yao]

Thanks! Personally I'd rather make getComputedStyle(el) always equivalent to el.ownerDocument.defaultView.getComputedStyle(el). Current behavior in the spec is hard to understand, and I doubt there are any real world use cases.

Comment 6

[Boris Zbarsky [:bzbarsky]]

> Personally I'd rather make getComputedStyle(el) always equivalent to
> el.ownerDocument.defaultView.getComputedStyle(el).

Pretty sure that's not web-compatible in the cases when el.ownerDocument.defaultView is null, since no UA throws in those cases...

Comment 7

[Anne (:annevk)]

I think we should flush the layout of the element that is passed. Not the layout of the window/document where getComputedStyle was invoked upon. This probably hits a fair amount of library code, e.g., this bug from jQuery:

  https://github.com/jquery/jquery/issues/2622

Comment 8

[Boris Zbarsky [:bzbarsky]]

> I think we should flush the layout of the element that is passed.

That will break cases when in fact the styles changed in the document being used for style information and that document is not that of the element.

Really, we should be flushing the thing that the style information comes from, but we can't even determine _that_ right now until we perform a flush.  I suppose we could just flush both documents, in cases when they're different...  It'll mean that doing cross-frame getComputedStyle like this is slower, but it's been best practice for years to not do it anyway because it's so broken in the spec and across browsers, so...

Comment 9

[Anne (:annevk)]

Apparently the CSS WG is considering making changes for getting resolved values from nodes not in the rendered document: https://lists.w3.org/Archives/Public/www-style/2016May/0021.html.

Still, it seems we should be able to determine whether the node is in a document that's associated with a browsing context/viewport, no? And in that case we'd use the style information from that document and otherwise that associated with the caller.