Open Bug 863485 Opened 8 years ago Updated 4 years ago

[webvtt] <track> does not parse data: URIs

Categories

(Core :: Audio/Video: Playback, defect)

x86_64
Linux
defect
Not set
normal

Tracking

()

REOPENED

People

(Reporter: rillian, Unassigned)

References

(Blocks 1 open bug, )

Details

(Keywords: dev-doc-needed)

Investigating the opera webvtt test suite I ran to an issue where we don't appear to handle data URI's for track.src. The test has code like:

  var t = document.createElement('track');
  t.src = 'data:text/vtt,'+encodeURIComponent('WEBVTT\n\n00:00.000 --> 00:01.000\nfoo');

We don't display anything with a source like this.

Test example: https://people.xiph.org/~giles/2013/vtt-01.html

Original Opera test: http://w3c-test.org/web-platform-tests/master/old-tests/submission/Opera/media/track/track-element/cloneNode.html although it's outdated in ways that don't agree with the current spec.
This isn't important until after we have more basic features working, but I wanted to get it tracked.
Tested with https://github.com/RickEyre/mozilla-central.git integration branch commit de894e21b1ae69c07648e917f3ccd5052a84e73b and media.webvtt.enabled=true in about:config.
FWIW, Chrome Canary 28 reports a CORS violation on the data uri.
heh that's weird, how do you get a CORS violation from local data @_@
heh that's weird, how do you get a CORS violation from local data @_@ like is that a desirable behaviour?

I mean, should we consider that to be a CORS violation in mozilla? (I don't know how we currently behave in this situation)
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Thanks for reopening this dbaron, there are real world examples like http://neocities.org that don't allow text/vtt files to be uploaded where this would be useful.
I've created jsfiddle:
http://jsfiddle.net/fixedmachine/ronaet82/

with sample which is addressing this issue. 

In Firefox 36.0.4 data URIs for <track> elements already seems to work fine, and it's the only browser right now with proper data URIs handling within <track> elements.

Chromium and WebKit based browsers report CORS errors. Internet Explorer 11 doesn't report any errors, but the subtitles embedded with data URI won't work.

I've tracked issues for:
- Chromium: https://code.google.com/p/chromium/issues/detail?id=472300
- WebKit: https://bugs.webkit.org/show_bug.cgi?id=143284
- Internet Explorer: https://connect.microsoft.com/IE/feedbackdetail/view/1217043/ie11-no-subtitles-displayed-when-track-element-has-src-specified-as-data-uri
Component: Audio/Video → Audio/Video: Playback
You need to log in before you can comment on or make changes to this bug.