When clicking on an Ogg video URL, or entering the URL via the URL bar, the duration is not known and seeking is disabled if the server does not send an Accept-Ranges header. An example of such a server is Amazon S3. It supports byte range requests but does not send an Accept-Ranges header. Links to videos on Amazon that are in <video> elements in a web page work fine, showing the duration and allowing seeking. Directly accessing a video in the browser does not provide a duration or seeking support however. This is because the nsVideoDocument provides the channel to the video decoder - the decoder code doesn't get the chance to send a special "0-" range request and look for a 216 response code to indicate seeking support. Steps to Reproduce: 1) Visit video in URL What is Expected: 1) Duration 2) Seeking allowed What actually happens: 1) No Duration 2) Cannot seek Some discussion on ways of fixing this: 1) Instead of seeking to find the duration with the current channel, open a new channel in parallel to seek and find the duration or 2) Check the URL extension/mime type and if it is an Ogg URL, send a "0-100" range request and check the response code.
This seems fixed in current nightly.
Chris, can you confirm if this bug exists on the latest Nightly?
The linked video now works because it's being served with an |Accept-Ranges: bytes| header. The bug is still present given the correct conditions, so we'll need to find a new testcase.
Yes, Amazon recently added Accept-Ranges to their S3 service which breaks the test case.
I haven't found a server that behave like S3 used to behave, so I wrote a quick node-based webserver which behaves the in the same way : http://paul.cx/node/. It replies to range request only if asked to (using a "0-" header as pointed in comment 1). If no such header is sent, it replies with a normal response (200, followed by the content).