Bug 163592 – Shadow hosts aren't automatically containing blocks for positioned descendants

• Status: RESOLVED
• Resolution: WONTFIX
• Component: Layout and Rendering

[Antoine Quint]

As of http://trac.webkit.org/changeset/207436, turning on the Development > Experimental Features > Modern Media Controls flag will use a different codebase for media controls. While it's limited in terms of feature right now (more patches are going to land throughout the week), it has the basic functionality of showing a play button over a <video> element on macOS and allowing for that button to be clicked to show a whole set of controls laid out in a controls bar at the bottom of the video as it starts playing. Right now, the initial play displays correctly, but once clicked the controls bar doesn't appear. Showing the Web Inspector makes the controls bar render correctly.

[Radar WebKit Bug Importer]

<rdar://problem/28820129>

[Antoine Quint]

Created attachment 291933 [details]
Testcase

[Antti Koivisto]

--- Source/WebCore/Modules/modern-media-controls/controls/media-controls.css	(revision 207457)
+++ Source/WebCore/Modules/modern-media-controls/controls/media-controls.css	(working copy)
@@ -23,7 +23,9 @@
  * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  */
 
-.media-controls,
+.media-controls {
+    position: relative;
+}
 .media-controls > .controls-bar {
     position: absolute;

makes them show up

[Antoine Quint]

Created attachment 291950 [details]
Patch

[Alexey Proskuryakov]

Comment on attachment 291950 [details]
Patch

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

> Source/WebCore/ChangeLog:12
> +        instead, which removes the rendering issues.

What bug tracks fixing the root cause?

[Antoine Quint]

(In reply to comment #5)
> Comment on attachment 291950 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=291950&action=review
> 
> > Source/WebCore/ChangeLog:12
> > +        instead, which removes the rendering issues.
> 
> What bug tracks fixing the root cause?

I suppose this should be kept as the bug tracking the original issue. I doubt it'll get fixed once we have a workaround though.

[Antti Koivisto]

Root cause appears to be in RenderImage (where RenderMedia inherits it). Since position:absolute makes little sense in UA shadow tree root element I don't think there is any particular desire to fix this.

[Antti Koivisto]

Not that I'm stopping anyone.

[Simon Fraser (smfr)]

(In reply to comment #7)
> Root cause appears to be in RenderImage (where RenderMedia inherits it).
> Since position:absolute makes little sense in UA shadow tree root element I
> don't think there is any particular desire to fix this.

What about RenderImage?

[Antti Koivisto]

> What about RenderImage?

What about it?

[Simon Fraser (smfr)]

You say "Root cause appears to be in RenderImage" but don't explain what it is.

[Antti Koivisto]

The issue is about UA shadow trees of renderers derived from RenderImage using absolute positioning in their shadows.

This is what I said in a mail about this

"The problem appears to be that you are using absolute positioned container as the rendering root of your shadow tree. Absolute positioning inside shadow trees works the same as it does outside so your controls end up being relative to the body, not <video>. Not sure why it doesn’t show up at all, maybe something to do with the wackiness of RenderImage::layoutShadowControls."

and

"I’m not sure I would even call it a workaround. Using absolute positioning in the root of a shadow tree is strange since the host element is not going to be your containing block. It is very easy to get such shadow to render outside the host (for example left:0px top:0px will put it to the top left corner of the document)."

[Alexey Proskuryakov]

Yes, it doesn't seem to make sense indeed. Can an assertion be added to catch trying to do this in UA shadow trees?

[Simon Fraser (smfr)]

Should the spec say that shadow roots always have position: relative (or words about acting as containing block and/or stacking context)?

[Antti Koivisto]

(In reply to comment #14)
> Should the spec say that shadow roots always have position: relative (or
> words about acting as containing block and/or stacking context)?

Shadow roots have no rendering at all. Children of shadow root act like direct children of the host. The host can be also be inline.

I'm not sure there is problem to solve as position:relative should generally give you what you want and position:absolute behavior is still consistent (bugs in special-renderer UA shadow trees notwithstanding).

[Ryosuke Niwa]

(In reply to comment #14)
> Should the spec say that shadow roots always have position: relative (or
> words about acting as containing block and/or stacking context)?

There was a discussion to use display: block as the default styling for shadow roots:
https://github.com/w3c/webcomponents/issues/426

[Ryosuke Niwa]

The current discussion hinges on adding a "lightweight" way to style custom elements: https://github.com/w3c/webcomponents/issues/468

[Antti Koivisto]

> There was a discussion to use display: block as the default styling for
> shadow roots:

Shadow hosts. And this wouldn't be useful here as the host is a replaced inline element.

[Ryosuke Niwa]

The current behavior matches the spec. We need to modify the host's style in order to do this, and nobody wanted attaching a shadow root to have that kind of side-effect in style.