163592 2016-10-18 01:48:41 -0700 Shadow hosts aren't automatically containing blocks for positioned descendants 2017-07-25 17:05:39 -0700 1 1 1 Unclassified WebKit Layout and Rendering Safari 10 Unspecified Unspecified RESOLVED WONTFIX InRadar P2 Normal --- 1 graouts graouts ap graouts koivisto rniwa simon.fraser webkit-bug-importer oldest_to_newest 1241384 0 graouts 2016-10-18 01:48:41 -0700 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. 1241386 1 webkit-bug-importer 2016-10-18 01:49:32 -0700 <rdar://problem/28820129> 1241387 2 291933 graouts 2016-10-18 02:19:30 -0700 Created attachment 291933 Testcase 1241436 3 koivisto 2016-10-18 08:06:23 -0700 --- 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 1241458 4 291950 graouts 2016-10-18 09:34:15 -0700 Created attachment 291950 Patch 1241462 5 291950 ap 2016-10-18 09:52:21 -0700 Comment on attachment 291950 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? 1241466 6 graouts 2016-10-18 10:04:10 -0700 (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. 1241485 7 koivisto 2016-10-18 10:30:00 -0700 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. 1241488 8 koivisto 2016-10-18 10:35:33 -0700 Not that I'm stopping anyone. 1241493 9 simon.fraser 2016-10-18 10:41:51 -0700 (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? 1241498 10 koivisto 2016-10-18 10:48:45 -0700 > What about RenderImage? What about it? 1241500 11 simon.fraser 2016-10-18 10:50:27 -0700 You say "Root cause appears to be in RenderImage" but don't explain what it is. 1241501 12 koivisto 2016-10-18 10:54:30 -0700 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)." 1241524 13 ap 2016-10-18 11:39:15 -0700 Yes, it doesn't seem to make sense indeed. Can an assertion be added to catch trying to do this in UA shadow trees? 1241527 14 simon.fraser 2016-10-18 11:41:36 -0700 Should the spec say that shadow roots always have position: relative (or words about acting as containing block and/or stacking context)? 1241536 15 koivisto 2016-10-18 12:06:01 -0700 (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). 1241594 16 rniwa 2016-10-18 13:40:01 -0700 (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 1241597 17 rniwa 2016-10-18 13:41:58 -0700 The current discussion hinges on adding a "lightweight" way to style custom elements: https://github.com/w3c/webcomponents/issues/468 1241632 18 koivisto 2016-10-18 14:59:47 -0700 > 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. 1332170 19 rniwa 2017-07-25 17:05:39 -0700 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. 291933 2016-10-18 02:19:30 -0700 2016-10-18 02:19:30 -0700 Testcase simple-video.html text/html 230 graouts PHZpZGVvIHNyYz0iaHR0cDovL21vdmlldHJhaWxlcnMuYXBwbGUuY29tL21vdmllcy9kaXNuZXkv aW5zaWRlb3V0L2luc2lkZW91dC11c2NhLXRscjJfNDgwcC5tb3YiIHBvc3Rlcj0iaHR0cDovL3Ry YWlsZXJzLmFwcGxlLmNvbS90cmFpbGVycy9kaXNuZXkvaW5zaWRlb3V0L2ltYWdlcy90aHVtYm5h aWxfc291cmNlXzIxMDAxLmpwZyIgc3R5bGU9IndpZHRoOiA4NDhweCIgY29udHJvbHM+PC92aWRl bz4= 291950 2016-10-18 09:34:15 -0700 2016-10-18 10:20:49 -0700 Patch bug-163592-20161018183040.patch text/plain 1738 graouts U3VidmVyc2lvbiBSZXZpc2lvbjogMjA3NDY0CmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViQ29yZS9D aGFuZ2VMb2cgYi9Tb3VyY2UvV2ViQ29yZS9DaGFuZ2VMb2cKaW5kZXggOWRmYmY2Yzc5ZGYwZTQ0 MzI3YmM2MGE3ZjgxNmI1MmEyNzc4MTQyOS4uNTZmYjk0NjUyZTQzYmE3MjQ2MzdhYmIyZTZkNzYw OWE1NTQ5NzM5ZSAxMDA2NDQKLS0tIGEvU291cmNlL1dlYkNvcmUvQ2hhbmdlTG9nCisrKyBiL1Nv dXJjZS9XZWJDb3JlL0NoYW5nZUxvZwpAQCAtMSwzICsxLDIwIEBACisyMDE2LTEwLTE4ICBBbnRv aW5lIFF1aW50ICA8Z3Jhb3V0c0BhcHBsZS5jb20+CisKKyAgICAgICAgTW9kZXJuIG1lZGlhIGNv bnRyb2xzIGRvbid0IHVwZGF0ZSB0aGVpciByZW5kZXJpbmcgY29ycmVjdGx5CisgICAgICAgIGh0 dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD0xNjM1OTIKKyAgICAgICAgPHJk YXI6Ly9wcm9ibGVtLzI4ODIwMTI5PgorCisgICAgICAgIFJldmlld2VkIGJ5IE5PQk9EWSAoT09Q UyEpLgorCisgICAgICAgIFRoZXJlIGFyZSByZW5kZXJpbmcgaXNzdWVzIHdoZW4gd2UgdXNlIGFu IGFic29sdXRlbHktcG9zaXRpb25lZCBlbGVtZW50CisgICAgICAgIGFzIHRoZSB0b3AtbW9zdCBl bGVtZW50IGluIGEgbWVkaWEgZWxlbWVudCdzIHNoYWRvdyByb290LiBTaW5jZSB3ZSBvbmx5Cisg ICAgICAgIG5lZWQgZm9yIHRoYXQgZWxlbWVudCB0byBiZSBwb3NpdGlvbmVkLCB3ZSBjYW4gdXNl ICJwb3NpdGlvbjogcmVsYXRpdmUiCisgICAgICAgIGluc3RlYWQsIHdoaWNoIHJlbW92ZXMgdGhl IHJlbmRlcmluZyBpc3N1ZXMuCisKKyAgICAgICAgKiBNb2R1bGVzL21vZGVybi1tZWRpYS1jb250 cm9scy9jb250cm9scy9tZWRpYS1jb250cm9scy5jc3M6CisgICAgICAgICgubWVkaWEtY29udHJv bHMpOgorICAgICAgICAoLm1lZGlhLWNvbnRyb2xzLCk6IERlbGV0ZWQuCisKIDIwMTYtMTAtMTgg IEVyaWMgQ2FybHNvbiAgPGVyaWMuY2FybHNvbkBhcHBsZS5jb20+CiAKICAgICAgICAgW01lZGlh U3RyZWFtXSBSZXNvbHZlIGNvbnN0cmFpbnRzIGFuZCBlbnVtZXJhdGUgZGV2aWNlcyBpbiB0aGUg VUkgcHJvY2VzcwpkaWZmIC0tZ2l0IGEvU291cmNlL1dlYkNvcmUvTW9kdWxlcy9tb2Rlcm4tbWVk aWEtY29udHJvbHMvY29udHJvbHMvbWVkaWEtY29udHJvbHMuY3NzIGIvU291cmNlL1dlYkNvcmUv TW9kdWxlcy9tb2Rlcm4tbWVkaWEtY29udHJvbHMvY29udHJvbHMvbWVkaWEtY29udHJvbHMuY3Nz CmluZGV4IGRiZDA0NDhiNGQ5OTU2ZjE1MjYzZjEwNmYzZDI0YjczNzM3ZTdjNTYuLjhiM2Y0ZDNm YWNlNGRlYjI4MTM1NGM4MzJmNzc5ZGM5MTkyODRiZDYgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9XZWJD b3JlL01vZHVsZXMvbW9kZXJuLW1lZGlhLWNvbnRyb2xzL2NvbnRyb2xzL21lZGlhLWNvbnRyb2xz LmNzcworKysgYi9Tb3VyY2UvV2ViQ29yZS9Nb2R1bGVzL21vZGVybi1tZWRpYS1jb250cm9scy9j b250cm9scy9tZWRpYS1jb250cm9scy5jc3MKQEAgLTIzLDcgKzIzLDEwIEBACiAgKiBPRiBUSElT IFNPRlRXQVJFLCBFVkVOIElGIEFEVklTRUQgT0YgVEhFIFBPU1NJQklMSVRZIE9GIFNVQ0ggREFN QUdFLgogICovCiAKLS5tZWRpYS1jb250cm9scywKKy5tZWRpYS1jb250cm9scyB7CisgICAgcG9z aXRpb246IHJlbGF0aXZlOworfQorCiAubWVkaWEtY29udHJvbHMgPiAuY29udHJvbHMtYmFyIHsK ICAgICBwb3NpdGlvbjogYWJzb2x1dGU7CiB9Cg==