New issue
Advanced search Search tips

Issue 592830 link

Starred by 2 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug



Sign in to add a comment

media element load should not start on removing |src| content attribute

Project Member Reported by tkent@chromium.org, Mar 8 2016

Issue description

Version: 51 canary
OS: All

What steps will reproduce the problem?
(1) Open http://w3c-test.org/html/semantics/embedded-content/media-elements/loading-the-media-resource/resource-selection-invoke-remove-src.html

What is the expected output? What do you see instead?
Expected: The test passes.
Actual: The test fails.


Please use labels and text to provide additional information.

The specification is very obvious.

https://html.spec.whatwg.org/multipage/embedded-content.html#dom-media-src
> If a src attribute of a media element is set or changed, the user agent must invoke the media element's media element load algorithm. (Removing the src attribute does not do this, even if there are source elements present.)

The test passes on Firefox and Edge.


 

Comment 1 by phil...@opera.com, Mar 9 2016

Cc: sim...@opera.com
I think simonp@opera.com wrote this test for Presto originally.

HTMLMediaElement::parseAttribute actually doesn't do anything when removing the src attribute, but it looks like this test is failing due to another bug.

The test has two scripts, and that is because per spec, the resource selection algorithm should "await a stable state", which is now equivalent to queuing a microtask. So per spec, when the second scripts starts running, the resource selection algorithm should already have looked at the src attribute and done nothing because its value was empty.

At that point, removing the src attribute shouldn't do anything additionally, and if it did kick of resource selection the error event would fire on the source element already added.

This doesn't work in Blink because the resource selection algorithm doesn't queue a microtask to continue, but instead starts a timer, which is more like a normal task, so it won't have run by the time the next script is encountered.

This is also why several others of these tests fail, at least some of those that fail on networkState being 0 while expecting 3 or vice versa.

I'll file a new tracking bug and update https://docs.google.com/spreadsheets/d/1-xlh6co6QYC-KVof27sVxjA7yuUFvYcaul3vE5dGHso/edit#gid=0

Comment 2 by phil...@opera.com, Mar 9 2016

I've filed issue 593289 and linked an number of test failures to that in the spreadsheet. tkent@, if you like you can dupe this issue into that one, but it doesn't really hurt to track them separately either.

Comment 3 by sshru...@google.com, Mar 21 2016

Components: -Blink>Audio Blink>Media>Audio
Renaming Blink>Audio to Blink>Media>Audio for better characterization

Comment 4 by sshru...@google.com, Mar 21 2016

Components: -Blink>Video Blink>Media>Video
Renaming Blink>Video to Blink>Media>Video for better characterization
Labels: Needs-BlinkMediaTriage

Comment 6 Deleted

Labels: -Needs-BlinkMediaTriage

Comment 8 by sim...@opera.com, Sep 14 2017

Cc: -sim...@opera.com zcorpan@gmail.com
Cc: mlamouri@chromium.org
Components: -Blink>Media>Audio -Blink>Media>Video Blink>Media
Some compat info:
- Works on Safari and Edge;
- Broken on Chrome and Firefox.

Sign in to add a comment