Bug 84378 – [GTK] media/track/track-cue-rendering-snap-to-lines-not-set.html fails

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKitGTK

[Philippe Normand]

Consistently. Diff:

--- /home/slave/webkitgtk/gtk-linux-64-release/build/layout-test-results/media/track/track-cue-rendering-snap-to-lines-not-set-expected.txt 
+++ /home/slave/webkitgtk/gtk-linux-64-release/build/layout-test-results/media/track/track-cue-rendering-snap-to-lines-not-set-actual.txt 
@@ -2,7 +2,7 @@
 EVENT(canplaythrough)
 
 The track container and the media controls should completely cover the video element
-EXPECTED (cueDisplayContainer.offsetHeight + controlsPanelElement.offsetHeight == video.videoHeight == 'true') OK
+EXPECTED (cueDisplayContainer.offsetHeight + controlsPanelElement.offsetHeight == video.videoHeight == 'true'), OBSERVED 'false' FAIL
 EXPECTED (cueDisplayContainer.offsetWidth == video.videoWidth == 'true') OK
 
 ** Default **

This test was introduced in 
http://trac.webkit.org/changeset/114640

[Victor Carbune]

(In reply to comment #0)
> Consistently. Diff:
> 
> --- /home/slave/webkitgtk/gtk-linux-64-release/build/layout-test-results/media/track/track-cue-rendering-snap-to-lines-not-set-expected.txt 
> +++ /home/slave/webkitgtk/gtk-linux-64-release/build/layout-test-results/media/track/track-cue-rendering-snap-to-lines-not-set-actual.txt 
> @@ -2,7 +2,7 @@
>  EVENT(canplaythrough)
> 
>  The track container and the media controls should completely cover the video element
> -EXPECTED (cueDisplayContainer.offsetHeight + controlsPanelElement.offsetHeight == video.videoHeight == 'true') OK
> +EXPECTED (cueDisplayContainer.offsetHeight + controlsPanelElement.offsetHeight == video.videoHeight == 'true'), OBSERVED 'false' FAIL
>  EXPECTED (cueDisplayContainer.offsetWidth == video.videoWidth == 'true') OK
> 
>  ** Default **
> 
> This test was introduced in 
> http://trac.webkit.org/changeset/114640
I believe this particular check fails because the -webkit-media-controls-panel element is absolutely positioned in mediaControlsGTK.

This change from absolute to relative positioning is required because the area on top of the video is now a flexible box, with two main boxes on top of each other: cue container box and control panel element.

If the panel element is absolutely positioned the flexible box is not positioning it, and the cue container expands towards the bottom of the video.

[Philippe Normand]

(In reply to comment #1)
> (In reply to comment #0)
> > Consistently. Diff:
> > 
> > --- /home/slave/webkitgtk/gtk-linux-64-release/build/layout-test-results/media/track/track-cue-rendering-snap-to-lines-not-set-expected.txt 
> > +++ /home/slave/webkitgtk/gtk-linux-64-release/build/layout-test-results/media/track/track-cue-rendering-snap-to-lines-not-set-actual.txt 
> > @@ -2,7 +2,7 @@
> >  EVENT(canplaythrough)
> > 
> >  The track container and the media controls should completely cover the video element
> > -EXPECTED (cueDisplayContainer.offsetHeight + controlsPanelElement.offsetHeight == video.videoHeight == 'true') OK
> > +EXPECTED (cueDisplayContainer.offsetHeight + controlsPanelElement.offsetHeight == video.videoHeight == 'true'), OBSERVED 'false' FAIL
> >  EXPECTED (cueDisplayContainer.offsetWidth == video.videoWidth == 'true') OK
> > 
> >  ** Default **
> > 
> > This test was introduced in 
> > http://trac.webkit.org/changeset/114640
> I believe this particular check fails because the -webkit-media-controls-panel element is absolutely positioned in mediaControlsGTK.
> 
> This change from absolute to relative positioning is required because the area on top of the video is now a flexible box, with two main boxes on top of each other: cue container box and control panel element.
> 
> If the panel element is absolutely positioned the flexible box is not positioning it, and the cue container expands towards the bottom of the video.

Thanks Victor!
I was just trying to figure out why the media controls panel was invisible now... And I remembered this bug. Will try your proposed solution and upload a patch.

[Philippe Normand]

The invisible controls timeline is a different issue, sorry for the noise.

[Philippe Normand]

Created attachment 139635 [details]
Patch

[Philippe Normand]

(In reply to comment #4)
> Created an attachment (id=139635) [details]
> Patch

When landing this the files DerivedSources/WebCore/UserAgentStyleSheetsData* should be removed on the bots to ensure the updated CSS file is parsed during the build.

[Build Bot]

Comment on attachment 139635 [details]
Patch

Attachment 139635 [details] did not pass win-ews (win):
Output: http://queues.webkit.org/results/12587591

[Philippe Normand]

Committed r115829: <http://trac.webkit.org/changeset/115829>

[Philippe Normand]

Hum this patch introduced a regression: bug 85376