RESOLVED FIXED Bug 106743
[EFL] media/video-controls-captions.html fails after r139547
https://bugs.webkit.org/show_bug.cgi?id=106743
Summary [EFL] media/video-controls-captions.html fails after r139547
Chris Dumez
Reported 2013-01-13 04:24:59 PST
<http://trac.webkit.org/changeset/139547> added additional checks to media/video-controls-captions.html and some of them are failing on EFL port: --- /home/buildslave-1/webkit-buildslave/efl-linux-64-debug-wk2/build/layout-test-results/media/video-controls-captions-expected.txt +++ /home/buildslave-1/webkit-buildslave/efl-linux-64-debug-wk2/build/layout-test-results/media/video-controls-captions-actual.txt @@ -25,8 +25,8 @@ ** Remove DOM node representing the track element ** ** Caption button should not be visible as there are no caption tracks. -EXPECTED (captionsButtonCoordinates[0] <= '0') OK -EXPECTED (captionsButtonCoordinates[1] <= '0') OK +EXPECTED (captionsButtonCoordinates[0] <= '0'), OBSERVED '330' FAIL +EXPECTED (captionsButtonCoordinates[1] <= '0'), OBSERVED '328' FAIL ** Add a text track through JS to the video element **
Attachments
Victor Carbune
Comment 1 2013-01-15 08:03:42 PST
I'm trying to figure out what happens that triggers this behavior. I can't think of any reason why MediaControls::closedCaptionTracksChanged() wouldn't be called in the same way as it on the Chromium port (since it seems to be triggered only in HTMLMediaElement). Would you be aware of any reason for which m_mediaController->hasClosedCaptions() would return true instead of false, in the case of removing the single <track> element from the DOM tree?
Chris Dumez
Comment 2 2013-02-18 01:08:23 PST
This failure is no longer reproducible.
Note You need to log in before you can comment on or make changes to this bug.