Bug 194516 – Entering fullscreen inside a shadow root will not set fullscreen pseudoclasses outside of root

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[Jer Noble]

Entering fullscreen inside a shadow root will not set fullscreen pseudoclasses outside of root

[Jer Noble]

<rdar://problem/44678353>

[Jer Noble]

Created attachment 361715 [details]
Patch

[EWS Watchlist]

Comment on attachment 361715 [details]
Patch

Attachment 361715 [details] did not pass ios-sim-ews (ios-simulator-wk2):
Output: https://webkit-queues.webkit.org/results/11114792

New failing tests:
fast/shadow-dom/fullscreen-in-shadow-full-screen-ancestor.html

[EWS Watchlist]

Created attachment 361741 [details]
Archive of layout-test-results from ews122 for ios-simulator-wk2

The attached test failures were seen while running run-webkit-tests on the ios-sim-ews.
Bot: ews122  Port: ios-simulator-wk2  Platform: Mac OS X 10.13.6

[Antoine Quint]

Comment on attachment 361715 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=361715&action=review

> Source/WebCore/dom/Element.cpp:3413
> +    return element->document().ownerElement();

Does that change this method's behaviour? Note that it's also used by Element::computedTouchActions() to iterate through parents of an element (regardless of compositing status, assuming "composed tree" here is related to that) going all the way through hosting frames.

[Antoine Quint]

(In reply to Antoine Quint from comment #5)
> Comment on attachment 361715 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=361715&action=review
> 
> > Source/WebCore/dom/Element.cpp:3413
> > +    return element->document().ownerElement();
> 
> Does that change this method's behaviour? Note that it's also used by
> Element::computedTouchActions() to iterate through parents of an element
> (regardless of compositing status, assuming "composed tree" here is related
> to that) going all the way through hosting frames.

Answering my own question, I guess not, since only the call to parentElement() changes.

[Jer Noble]

(In reply to Antoine Quint from comment #5)
> Comment on attachment 361715 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=361715&action=review
> 
> > Source/WebCore/dom/Element.cpp:3413
> > +    return element->document().ownerElement();
> 
> Does that change this method's behaviour? Note that it's also used by
> Element::computedTouchActions() to iterate through parents of an element
> (regardless of compositing status, assuming "composed tree" here is related
> to that) going all the way through hosting frames.

I did note, and pointed this out to Ryosuke, who said the current behavior was wrong there too.

> Answering my own question, I guess not, since only the call to parentElement() changes.

Yes, the difference between parentElement() and parentElementInComposedTree() has to do with how Shadow DOM nodes are "composed" together into the final DOM tree, and not really about the render tree.

[Jer Noble]

Created attachment 361939 [details]
Patch for landing

[WebKit Commit Bot]

Comment on attachment 361939 [details]
Patch for landing

Clearing flags on attachment: 361939

Committed r241484: <https://trac.webkit.org/changeset/241484>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.