1129190 - Calling load() on a preload="none" video has no effect

Status: RESOLVED INVALID

(Core :: Audio/Video, defect)

Description

[Daniel Baulig]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.94 Safari/537.36

Steps to reproduce:

Create a video tag with controls and preload="none" attributes.
From JavaScript assign a src attribute and call load() on the video tag.

See jsfiddle: http://jsfiddle.net/kwaj7a5s/

Setting perload="auto" instead will load the video correctly.


Actual results:

Nothing in Firefox 35.0.1

For reference: works as expected in Chrome 40.0.2214.94 (64-bit)


Expected results:

The video should start loading, causing a HTTP request to the video file and various metadata in the player controls to be populated (e.g. total playback time, video dimensions, first frame rendered).

Comment 1

[Till Schneidereit [:till]]

Needinfo'ing Anthony as this blocks video players we care about.

Comment 2

[Chris Peterson [:cpeterson]]

[Tracking Requested - why for this release]:

We'd like to uplift a fix to 37 (Aurora or Beta) to unblock a partner testing HTML5 video.

Comment 4

[Karl Tomlinson (:karlt)]

(In reply to Daniel Baulig from comment #0)
> From JavaScript assign a src attribute and call load() on the video tag.

Calling load() after setting |src| should reset any existing load, but not do
anything different from the load algorithm invoked when |src| was set.

If the preload="none" behavior is not the desired behavior, then I'd recommend
changing the |preload| attribute.

> Expected results:
> 
> The video should start loading, causing a HTTP request to the video file and
> various metadata in the player controls to be populated (e.g. total playback
> time, video dimensions, first frame rendered).

This would be the expected result with preload="metadata", but still the load() has no useful effect after setting |src|.

preload="none" behavior is implied by the spec:

http://www.w3.org/TR/2014/WD-html51-20140617/embedded-content.html#dom-media-load

"When the load() method on a media element is invoked, the user agent must run the media element load algorithm."

http://www.w3.org/TR/2014/WD-html51-20140617/embedded-content.html#media-element-load-algorithm

7. Invoke the media element's resource selection algorithm.

http://www.w3.org/TR/2014/WD-html51-20140617/embedded-content.html#concept-media-load-algorithm

9. If mode is attribute, then run these substeps:

5. If absolute URL was obtained successfully, run the resource fetch algorithm
   with absolute URL. If that algorithm returns without aborting this one,
   then the load failed.

http://www.w3.org/TR/2014/WD-html51-20140617/embedded-content.html#concept-media-load-resource

3. Optionally, run the following substeps. This is the expected behavior if the user agent intends to not attempt to fetch the resource until the user requests it explicitly (e.g. as a way to implement the preload attribute's none keyword).

  1. Set the networkState to NETWORK_IDLE.

  2. Queue a task to fire a simple event named suspend at the element.

  3. Queue a task to set the element's delaying-the-load-event flag to false.
     This stops delaying the load event.

  4. Wait for the task to be run.

  5. Wait for an implementation-defined event (e.g. the user requesting that
     the media element begin playback).

Comment 5

[Karl Tomlinson (:karlt)]

(In reply to Chris Peterson [:cpeterson] from comment #2)
> We'd like to uplift a fix to 37 (Aurora or Beta) to unblock a partner
> testing HTML5 video.

I don't see a bug to fix here.  Perhaps this should be moved to evangelism.

I wouldn't recommend uplifting to Beta a behavior change to deviate from the spec.

Comment 6

[Chris Peterson [:cpeterson]]

Daniel, does Karl's recommendation to use preload="metadata" work for you? It looks like Chrome and WebKit are much more aggressive than Firefox as preloading and treat the <video> tag's preload="none" hint as preload="metadata". ajones just confirmed this in email.

I'm marking this bug as "resolved invalid" for now because it is not a Firefox bug, though Chrome's interpretation of the W3C spec is making Firefox look bad at the cost of consuming more of the user's network bandwidth.

Comment 7

[Daniel Baulig]

I currently already have a hack in place that sets preload temporarily to the "auto" value until I receive a canplay event. I do disagree with this interpretation of the spec though.

> 3. Optionally, run the following substeps. This is the expected behavior if the user agent intends to
> not attempt to fetch the resource until the user requests it explicitly

I feel like calling load is pretty explicit. I don't know how I could make my intentions more explicit.

Just for documentation's sake: if at some point I want to make a video start loading it's payload data without actually starting to play it, the correct way - according to spec - is to change the video elements preload attribute to metadata/auto, not calling the load method on the video element?

Comment 8

[Daniel Baulig]

Thanks a lot though for moving fast on this.

Comment 9

[Karl Tomlinson (:karlt)]

(In reply to Daniel Baulig from comment #7)
> Just for documentation's sake: if at some point I want to make a video start
> loading it's payload data without actually starting to play it, the correct
> way - according to spec - is to change the video elements preload attribute
> to metadata/auto, not calling the load method on the video element?

Yes, that's how I understand the spec and what I'd recommend.  These are hints that the user agent is not *required* to follow, but still that should be effective in Gecko at least.

The differences between the names "load" and "preload" perhaps don't correspond so well with the effects of these parts of the API.  "preload" more describes how much of the (async) resource fetch algorithm, initiated by the load algorithm, to complete before waiting until more data is required.

Comment 10

[Chris Peterson [:cpeterson]]

(In reply to Karl Tomlinson (:karlt) from comment #9)
> The differences between the names "load" and "preload" perhaps don't
> correspond so well with the effects of these parts of the API.  "preload"
> more describes how much of the (async) resource fetch algorithm, initiated
> by the load algorithm, to complete before waiting until more data is
> required.

Karl, what is the difference between assigning a value to the <video> element's src attribute and calling load()? Does setting the src attribute, without calling load(), also initiate the load algorithm?

MDN's description of load() [1] is "Begins loading the media content from the server." What is a more accurate description?

[1] https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaElement

Comment 11

[Karl Tomlinson (:karlt)]

(In reply to Chris Peterson [:cpeterson] from comment #10)
> Karl, what is the difference between assigning a value to the <video>
> element's src attribute and calling load()? Does setting the src attribute,
> without calling load(), also initiate the load algorithm?

Setting or changing the src attribute will do the equivalent of calling load().

This behavior is since http://lists.w3.org/Archives/Public/public-html-comments/2009Oct/0021.html and bug 485288.

> MDN's description of load() [1] is "Begins loading the media content from
> the server." What is a more accurate description?
> 
> [1] https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaElement

I've updated that.
https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaElement$compare?locale=en-US&to=740101&from=720039