Closed
Bug 696354
Opened 13 years ago
Closed 13 years ago
When a media load is redirected, currentSrc should return the pre-redirect URI
Categories
(Core :: Audio/Video, defect)
Tracking
()
VERIFIED
FIXED
mozilla11
People
(Reporter: zeno, Unassigned)
References
Details
(Keywords: verified-beta, Whiteboard: [mentor=jdm] [lang=c++])
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?
Comment 1•13 years ago
|
||
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Updated•13 years ago
|
Summary: HTML5 video, redirects and currentSrc → When a media load is redirected, currentSrc should return the pre-redirect URI
Reporter | ||
Comment 2•13 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" /> </video> (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•13 years ago
|
||
Relevant code: http://mxr.mozilla.org/mozilla-central/source/content/html/content/src/nsHTMLMediaElement.cpp#427 http://mxr.mozilla.org/mozilla-central/source/content/media/nsMediaStream.cpp#1178 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•13 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.
Updated•13 years ago
|
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Comment 6•13 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.
Comment 7•13 years ago
|
||
(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.
Comment 8•13 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/09d5d6e6dd28 fixed this.
Comment 9•13 years ago
|
||
Great, thanks!
Comment 10•13 years ago
|
||
Great, thanks for the quick fixing! :) In which "normal" release (not nightly nor beta) / When will it be available? Thanks again!
Comment 11•12 years ago
|
||
The fix from comment 8 landed on the firefox 11 tree. I should be in a stable release in March.
Updated•12 years ago
|
Target Milestone: --- → mozilla11
Comment 12•12 years ago
|
||
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"
Status: RESOLVED → VERIFIED
Keywords: verified-beta
You need to log in
before you can comment on or make changes to this bug.
Description
•