When a media load is redirected, currentSrc should return the pre-redirect URI

VERIFIED FIXED in mozilla11



6 years ago
5 years ago


(Reporter: Zeno Crivelli, Unassigned)



Mac OS X

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [mentor=jdm] [lang=c++])



6 years ago
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_2) AppleWebKit/534.51.22 (KHTML, like Gecko) Version/5.1.1 Safari/534.51.22

Steps to reproduce:

We've been running some tests where the <video> (or <source>)'s src value is not directly the final/real URL of the source, but rather an initial URL that'll get there via one or multiple redirects.

Actual results:

Firefox seems to be the only browser that will use the final/real URL when setting video.currentSrc. 

Expected results:

All the other browsers (Chrome, Safari, Opera, IE9) will set video.currentSrc to match the src value that was initially set in the <video> or <source> element.

Yet another browser inconsistency when it comes to HTML5 video implementation.

The HTML5 video spec says the src attribute's value should be "resolved" to an absolute URL. But it is my understanding that the "resolve" definition only actually implies the relative-to-absolute conversion, and it doesn't seem to imply that redirects should also be followed.

Hence the question, is this a bug?
Yeah, this looks like a bug.  We should probably store the originalURI of the channel to use as the currentSrc instead of using the URI of the channel.
Ever confirmed: true
Summary: HTML5 video, redirects and currentSrc → When a media load is redirected, currentSrc should return the pre-redirect URI

Comment 2

6 years ago
If you a redirecting-URL to test this out, you can use this: http://cl.ly/9U1B/dartmoor1_800.ogv

<video width="800" height="336" controls>
  <source src="http://cl.ly/9U1B/dartmoor1_800.ogv" />

(document.getElementsByTagName("video")[0].currentSrc should return "http://cl.ly/9U1B/dartmoor1_800.ogv" instead of "http://f.cl.ly/items/3e0I2Y3F1o3D0u041u03/dartmoor1_800.ogv")

Comment 3

6 years ago
Relevant code: http://mxr.mozilla.org/mozilla-central/source/content/html/content/src/nsHTMLMediaElement.cpp#427

Matthew, is it safe to just change the implementation of GetCurrentSpec, or will that mess up ProcessMediaFragmentURI? In any case, we probably want to expose an OriginalURI method on nsMediaStream that returns the originalURI member of the channel the stream receives.
Whiteboard: [mentor=jdm] [lang=c++]

Comment 4

6 years ago
This may have been negated by bug 703379, but I'm not sure. We still attempt to get the URI from the decoder instead of mLoadingSrc, and I haven't looked into at what point mLoadingSrc becomes available.
Depends on: 703379
I believe this will be fixed by bug 703379.
Last Resolved: 6 years ago
Resolution: --- → FIXED

Comment 6

6 years ago
Reuben, did you confirm that this is fixed by bug 703379? If not, it would be worth doing so before closing this bug.
(In reply to Josh Matthews [:jdm] from comment #6)
> Reuben, did you confirm that this is fixed by bug 703379? If not, it would
> be worth doing so before closing this bug.

I tried the nightly builds before and after the patches on that bug were pushed, and the problem disappeared in that range. I'll backout the specific changesets and make sure.
https://hg.mozilla.org/mozilla-central/rev/09d5d6e6dd28 fixed this.

Comment 9

6 years ago
Great, thanks!

Comment 10

6 years ago
Great, thanks for the quick fixing! :)

In which "normal" release (not nightly nor beta) / When will it be available?

Thanks again!
The fix from comment 8 landed on the firefox 11 tree. I should be in a stable release in March.
Target Milestone: --- → mozilla11
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20100101 Firefox/11.0
Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20100101 Firefox/11.0
Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20100101 Firefox/11.0

Verified the fix on the above builds (Firefox 11.0 beta 1), based on comment #2 : document.getElementsByTagName("video")[0].currentSrc returns "http://cl.ly/9U1B/dartmoor1_800.ogv"
Keywords: verified-beta
No longer depends on: 703379
Depends on: 703379
You need to log in before you can comment on or make changes to this bug.