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.
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").currentSrc should return "http://cl.ly/9U1B/dartmoor1_800.ogv" instead of "http://f.cl.ly/items/3e0I2Y3F1o3D0u041u03/dartmoor1_800.ogv")
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.
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.
I believe this will be fixed by bug 703379.
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.
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.
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").currentSrc returns "http://cl.ly/9U1B/dartmoor1_800.ogv"