New issue
Advanced search Search tips

Issue 811713 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner: ----
Closed: Mar 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug



Sign in to add a comment

Broken text tracks (<track> elements) can block video playback starting

Project Member Reported by foolip@chromium.org, Feb 13 2018

Issue description

https://github.com/w3c/web-platform-tests/pull/9495 has some test cases demonstrating this. Replacing autoplay with an explicit call to play() doesn't change the result in Chrome, so it's not directly related to the autoplay logic.

The problem is most likely related to TextTracksAreReady(), that it returns false when it shouldn't and therefore blocks readyState from progressing far enough to play. The spec has changed here as well with https://html.spec.whatwg.org/multipage/media.html#list-of-pending-text-tracks roughly playing the role of our text_tracks_when_resource_selection_began_. Trying to match the spec and seeing if it fixes the problem would be interesting, but there could be a smaller fix too.
 

Comment 1 by f...@opera.com, Feb 13 2018

Cc: sriram...@samsung.com
Labels: -Pri-3 Pri-2
Status: Available (was: Untriaged)
AFAICT, TextTracksAreReady does return true in all of these cases*. I might take a slightly deeper look and see if anything pops out...

* After fixing an issue with "" which wouldn't initiate a log for because we have a "url == url_" check which will be true for "" even the first time around - meaning we never made it out of 'not loaded' for that URL.

Comment 2 by f...@opera.com, Feb 13 2018

AFAICT, the ready state does advance as it should, but 'autoplay' won't happen because of the autoplay policy, so presumably you'll need to tweak the test to get around that. I'll land a fix for the src="" issue mentioned above though.

Comment 3 by foolip@chromium.org, Feb 13 2018

Yeah, I noticed a difference between Chrome stable and Chrome canary that I assumed had to do with autoplay changes. Problem should still be there in another form though.

Comment 4 by f...@opera.com, Feb 13 2018

If I pass/set --autoplay-policy=no-user-gesture-required then all the tests PASS (in my content_shell with the above fix.)

Comment 5 by foolip@chromium.org, Feb 13 2018

Sweet!
LayoutTests should be running with --autoplay-policy=no-user-gesture-required so WPT running in Blink should be passing.
Project Member

Comment 7 by bugdroid1@chromium.org, Feb 14 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/bfece13cc337e5ee9e874ba05edaab83b79f1371

commit bfece13cc337e5ee9e874ba05edaab83b79f1371
Author: Fredrik Söderquist <fs@opera.com>
Date: Wed Feb 14 09:08:48 2018

Setting "" as <track> 'src' should fail the first time

When setting a track .src to "", we would resolve the URL to a null URL,
which matched the default initialized HTMLTrackElement::url_, meaning
that readyState was not advanced and no 'error' event fired in this
case.

Extend the "url == url_" check with a check for readyState differing from
'none'. Also rewrite HTMLTrackElement::getReadyState to avoid using
EnsureTrack().

Bug:  811713 
Change-Id: Icd190492639c53e09a7e018202b69ac6e919a94c
Reviewed-on: https://chromium-review.googlesource.com/916004
Commit-Queue: Fredrik Söderquist <fs@opera.com>
Reviewed-by: srirama chandra sekhar <srirama.m@samsung.com>
Cr-Commit-Position: refs/heads/master@{#536685}
[add] https://crrev.com/bfece13cc337e5ee9e874ba05edaab83b79f1371/third_party/WebKit/LayoutTests/external/wpt/html/semantics/embedded-content/media-elements/track/track-element/src-empty-string.html
[modify] https://crrev.com/bfece13cc337e5ee9e874ba05edaab83b79f1371/third_party/WebKit/Source/core/html/track/HTMLTrackElement.cpp

Status: Fixed (was: Available)

Sign in to add a comment