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)

x86
macOS
defect
Not set
normal

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?
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
Summary: HTML5 video, redirects and currentSrc → When a media load is redirected, currentSrc should return the pre-redirect URI
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")
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++]
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
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
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!
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"
Status: RESOLVED → VERIFIED
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.