Bug 222657 – Media element never populates its UA shadow if it was initially created in a document without browsing context

• Status: RESOLVED
• Resolution: FIXED
• Component: Media

[Javan Makhmali]

Created attachment 422090 [details]
Test case

When input and media elements are adopted with document.adoptNode() from a foreign document (via DOMParser, for example) they lose their native shadow DOM roots and are left in a mostly broken state: <input>s lose their native UI, and <video> and <audio> elements lose their native controls.

To reproduce, open the attached adopt-node-bug.html file in Safari and compare the correct middle column (imported node) to the incorrect right column (adopted node).

Tested in Safari v14.0.3 (16610.4.3.1.4) on macOS v11.2.2, and mobile Safari on iOS v14.4.

[Javan Makhmali]

Created attachment 422091 [details]
Screenshot of the issue in Safari on macOS

[Javan Makhmali]

Created attachment 422092 [details]
Video recording of the issue in Safari on iOS

[Ryosuke Niwa]

That's not really a loss of Shadow DOM but more to do with us failing to update based on the type content attribute.

[Javan Makhmali]

Created attachment 422225 [details]
Adopted media elements with empty Shadow Content

> That's not really a loss of Shadow DOM but more to do with us failing to update based on the type content attribute.

Are you referring to the “type” attribute on <input> elements? For <audio> and <video> elements the Shadow Content does appear to be lost or empty (see attached media-elements.png screenshot). Not sure if it’s the same underlying issue.

[Ryosuke Niwa]

Input element issue should be fixed in Safari 14.1 in the bug 216985. The media element seems to be still broken.

[Ryosuke Niwa]

This isn't so much about adoptNode discarding the UA shadow tree of media element as much as media element not initialize its UA shadow root when it's created inside a document without a browsing context. The fix is to initialize the media element controls once it's inserted into a document with a browsing context.

[Ryosuke Niwa]

This is the fix:

diff --git a/Source/WebCore/html/HTMLMediaElement.cpp b/Source/WebCore/html/HTMLMediaElement.cpp
index e1d903331b07..291964180f72 100644
--- a/Source/WebCore/html/HTMLMediaElement.cpp
+++ b/Source/WebCore/html/HTMLMediaElement.cpp
@@ -4290,7 +4290,10 @@ void HTMLMediaElement::ensureMediaControlsShadowRoot()
         return;
 
     m_creatingControls = true;
-    ensureUserAgentShadowRoot();
+    if (auto shadowRoot = userAgentShadowRoot(); shadowRoot && !shadowRoot->hasChildNodes())
+        didAddUserAgentShadowRoot(*shadowRoot);
+    else
+        ensureUserAgentShadowRoot();
     m_creatingControls = false;
 }

[Radar WebKit Bug Importer]

<rdar://problem/75266631>

[Javan Makhmali]

> …media element not initialize its UA shadow root when it's created inside a document without a browsing context. The fix is to initialize the media element controls once it's inserted into a document with a browsing context.

Could bug 211620 be the same underlying issue?

[Ryosuke Niwa]

(In reply to Javan Makhmali from comment #9)
> > …media element not initialize its UA shadow root when it's created inside a document without a browsing context. The fix is to initialize the media element controls once it's inserted into a document with a browsing context.
> 
> Could bug 211620 be the same underlying issue?

No, img element doesn't use a shadow tree.

[Ryosuke Niwa]

*** Bug 68574 has been marked as a duplicate of this bug. ***

[Devin Rousso]

Pull request: https://github.com/WebKit/WebKit/pull/2955

[EWS]

Committed 253225@main (f331cc98c1de): <https://commits.webkit.org/253225@main>

Reviewed commits have been landed. Closing PR #2955 and removing active labels.