Last Comment Bug 696354 - When a media load is redirected, currentSrc should return the pre-redirect URI
: When a media load is redirected, currentSrc should return the pre-redirect URI
Status: VERIFIED FIXED
[mentor=jdm] [lang=c++]
: verified-beta
Product: Core
Classification: Components
Component: Audio/Video (show other bugs)
: unspecified
: x86 Mac OS X
: -- normal (vote)
: mozilla11
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
Depends on: 703379
Blocks:
  Show dependency treegraph
 
Reported: 2011-10-21 05:04 PDT by Zeno Crivelli
Modified: 2012-05-20 19:39 PDT (History)
8 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Zeno Crivelli 2011-10-21 05:04:58 PDT
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 Boris Zbarsky [:bz] 2011-10-21 05:08:43 PDT
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.
Comment 2 Zeno Crivelli 2011-10-21 07:04:33 PDT
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 Josh Matthews [:jdm] 2011-10-21 09:24:56 PDT
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.
Comment 4 Josh Matthews [:jdm] 2011-11-20 21:15:31 PST
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.
Comment 5 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2011-11-21 00:35:55 PST
I believe this will be fixed by bug 703379.
Comment 6 Josh Matthews [:jdm] 2011-12-02 11:46:29 PST
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 Reuben Morais [:reuben] 2011-12-02 15:48:58 PST
(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 Reuben Morais [:reuben] 2011-12-02 15:58:38 PST
https://hg.mozilla.org/mozilla-central/rev/09d5d6e6dd28 fixed this.
Comment 9 Josh Matthews [:jdm] 2011-12-03 06:05:12 PST
Great, thanks!
Comment 10 Rémy Coutable 2011-12-07 01:24:36 PST
Great, thanks for the quick fixing! :)

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

Thanks again!
Comment 11 Ralph Giles (:rillian) needinfo me 2012-01-05 11:57:20 PST
The fix from comment 8 landed on the firefox 11 tree. I should be in a stable release in March.
Comment 12 Mihaela Velimiroviciu (:mihaelav) 2012-02-06 06:50:58 PST
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"

Note You need to log in before you can comment on or make changes to this bug.