Issue metadata
Sign in to add a comment
|
CSSComputedStyleDeclaration::GetPropertyCSSValue might have issues with OOPIFs |
||||||||||||||||||||||||
Issue description
I noticed this code in CSSComputedStyleDeclaration::GetPropertyCSSValue while debugging something nearby [1]:
if (HTMLFrameOwnerElement* owner = document.LocalOwner()) {
// We are inside an iframe. If any of our ancestor iframes needs a style
// and/or layout update, we need to make that up-to-date to resolve viewport
// media queries and generate boxes as we might be moving to/from
// display:none in some element in the chain of ancestors.
//
// TODO(futhark@chromium.org): There is an open question what the computed
// style should be in a display:none iframe. If the property we are querying
// is not layout dependent, we will not update the iframe layout box here.
if (property_class.IsLayoutDependentProperty() ||
document.GetStyleEngine().HasViewportDependentMediaQueries()) {
owner->GetDocument().UpdateStyleAndLayout();
// The style recalc could have caused the styled node to be discarded or
// replaced if it was a PseudoElement so we need to update it.
styled_node = StyledNode();
}
}
chrishtr@: do you know if this will this work properly with OOPIFs? It seems that we want to trigger layout on the parent frame in some cases, but we won't do it if the FrameOwner is remote (causing document.LocalOwner() to return null).
[1] https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/css/CSSComputedStyleDeclaration.cpp?l=338&rcl=c3185f133384bcb1d257b26637ef045d85810bfd
,
Apr 4 2018
It's more likely an interop issue when the changes in the parent and child documents can be done in a deterministic order like when you change the style in the parent document and query the computed style of an element in the child document from a script in the parent document:
script in parent document:
iframe.style.width = "100px"
console.log(getComputedStyle(iframe.contentWindow.document.querySelector("#testdiv").color);
Now, if the #testdiv color relies on a media query triggering 100px width, it's deterministic and observable if iframe in the parent document is layed out and affected media query resolution in the child document as part of getComputedStyle().
For OOPIF, you cannot do cross frame scripting, right? Then, if you did a synchronous wait for the parent frame process to layout, you still couldn't be sure at which point in the process the parent frame is and even if such a synchronization was implemented and to some degree observable, it would not be predictable?
,
Apr 5 2018
Comment 2: Frames in different processes will never be same-origin, if that's what you mean. It is still possible to do postMessage between them (and the steps you describe sound fairly similar to those in issue 828529), so I wonder if that faces a similar risk?
,
Apr 5 2018
Yes, issue 828529 is just a variant using offsetWidth instead of getComputedStyle. Are you guaranteed per spec that the postMessage() in the top document is not handled in the iframe process before the top document script continues doing iframe.width = 800?
,
Apr 6 2018
,
Apr 6 2018
This is basically the same issue as 828529. Just different property accesses which both depend on the ancestor frames being clean. |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by kenrb@chromium.org
, Apr 4 2018