WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
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
Add attachment
proposed patch, testcase, etc.
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.
Top of Page
Format For Printing
XML
Clone This Bug