780379 - Firefox mobile cannot open .m3u8 file (broken file?)

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: Download Manager, defect)

Description

[Frank Wein [:mcsmurf]]

To reproduce:
1. Install MX Player from App Store (might be optional, not sure)
2. Try to open http://zdf_ios_de-i.akamaihd.net/hls/live/204576/de03_v1/med/playlist.m3u8 with Firefox (in my case I used an Aurora build and a mozilla-central nightly to test)

Actual results:
Firefox seems to try to open that file with MX Player as the screen (sometimes) briefly turns black; shortly after that Firefox appears again. When I tap on the download notification, MX Player tells me that it cannot play that file

Expected results:
To behave like Chrome (in this case :-). Chrome asked me the first time if I want to use the Android Video player or MX Player to open that file. The second time it remembered my decision. Playing the .m3u8 file worked fine.

Maybe this bug is a dupe of another bug, not sure. I will attach HTTP headers plus file content to compare Firefox

I tested this on a Samsung Galaxy S2 with Android 4.0

Comment 1

[Frank Wein [:mcsmurf]]

Attachment: HTTP request from Firefox mobile and Chrome mobile

It looks like Chrome and Firefox get the same data.

Comment 3

[alex]

http://ib7.islambox.tv/vod/_definst_/mp4:peter/1.mp4/playlist.m3u8
http://qthttp.apple.com.edgesuite.net/1010qwoeiuryfg/0150_vod.m3u8

this urls work fine in android browser(suggests to open it with Media Player), but Firefox just downloads them

tested on galaxy tab gt-p7510

Comment 4

[Lawrence Mandel [:lmandel] (use needinfo)]

Brad, this bug leads to audio/video compatibility issues. Can you please have someone review the request?

Comment 5

[Brad Lassey [:blassey] (use needinfo?)]

Am I right in assuming that if we pass this file off to another app on the system everyone would be happy?

The reason that isn't happening right now is that the system is telling us that there are no handlers for "application/x-mpegurl". Given that the media player handles it when clicked from the stock browser, that is surprising to me.

Comment 6

[Lawrence Mandel [:lmandel] (use needinfo)]

(In reply to Brad Lassey [:blassey] (use needinfo?) from comment #5)
> Am I right in assuming that if we pass this file off to another app on the
> system everyone would be happy?

Seems to me that would make everyone happy but I would like Hallvord to confirm.

> The reason that isn't happening right now is that the system is telling us
> that there are no handlers for "application/x-mpegurl". Given that the media
> player handles it when clicked from the stock browser, that is surprising to
> me.

Right. I would have thought that the apps would have specified a handler.

Comment 7

[Frank Wein [:mcsmurf]]

Naive(?) question on this: Does Firefox mobile pass on only the file itself or the URL of the file to the external media player(, too)? Just wondering how resolving relative URLs within playlists works in this case. As you can see from the attached http log, the playlist in question only contains some relative URLs (as far as I see this) that were resolved by the media player then (or was this done by the native browser?).

Comment 8

[Hallvord R. M. Steen [:hallvors]]

(In reply to Lawrence Mandel [:lmandel] from comment #6)
> (In reply to Brad Lassey [:blassey] (use needinfo?) from comment #5)
> > Am I right in assuming that if we pass this file off to another app on the
> > system everyone would be happy?
> 
> Seems to me that would make everyone happy but I would like Hallvord to
> confirm.

iPhone seems pretty happy to play it in fullscreen, so that should be ok.

Frank Wein points out an important gotcha..

Comment 9

[Brad Lassey [:blassey] (use needinfo?)]

Attachment: pattch to add getHandlersForUrl to nsIAndroidBridge

Comment 10

[Brad Lassey [:blassey] (use needinfo?)]

Attachment: patch to give option of passing a URI to a helper app

Comment 11

[Brad Lassey [:blassey] (use needinfo?)]

Attachment: whatDoYouWantToDo.png

ui review please (flag doesn't exist????)

Comment 12

[Brad Lassey [:blassey] (use needinfo?)]

just a note, this will show up when we have a mime type that Firefox can't handle. We currently just download it, which is broken for many mime types

Comment 13

[Brad Lassey [:blassey] (use needinfo?)]

Attachment: patch to include mime type info in intent request and not accept all mimetypes for VIEW action in our manifest

this applies on top of the previous two patches. The effect is to not have Firefox offering to view things it can't actually display. Notice in the screenshot I'll attach next that fennec_blassey is not listed as an option.

Comment 14

[Brad Lassey [:blassey] (use needinfo?)]

Attachment: whatDoYouWantToDo_Mime.png

Comment 15

[Wesley Johnston (:wesj)]

Comment on attachment 806708 [details] [diff] [review]
patch to give option of passing a URI to a helper app

Review of attachment 806708 [details] [diff] [review]:
-----------------------------------------------------------------

As much as I hate other languages, I think we probably should support them.

::: mobile/android/components/HelperAppDialog.js
@@ +25,5 @@
>  
>    show: function hald_show(aLauncher, aContext, aReason) {
> +
> +    var p = new Prompt({
> +	title: "What would you like to do with this? "

Localize this

@@ +28,5 @@
> +    var p = new Prompt({
> +	title: "What would you like to do with this? "
> +    });
> +    var handlerOptions = [{
> +	label: "save to disk",

And this

@@ +32,5 @@
> +	label: "save to disk",
> +        handler: null
> +    }];
> +    let defaultHandler = new Object();
> +    let handlers = Services.androidBridge.getHandlersForURI(aLauncher.source.spec, "", defaultHandler);

If there are no handlers, I think we want to just download?

@@ +43,5 @@
> +	    item.selected = true;
> +	handlerOptions.push(item);
> +    });
> +      
> +      p.setSingleChoiceItems(handlerOptions);

Looks like the tab spacing switches here?

@@ +48,5 @@
> +      p.show(function show(data) {
> +	  if (data.button == 0)
> +	      aLauncher.MIMEInfo.preferredAction = Ci.nsIMIMEInfo.saveToDisk;
> +	  else
> +	      aLauncher.MIMEInfo.preferredAction = Ci.nsIMIMEInfo.useHelperApp;

Should this cancel the download? (aLauncher.cancel()) Talked to you about just removing this.

Comment 16

[Brad Lassey [:blassey] (use needinfo?)]

Attachment: patch to give option of passing a URI to a helper app

Comment 17

[Kartikaya Gupta (email:[e-mail])]

Comment on attachment 806704 [details] [diff] [review]
pattch to add getHandlersForUrl to nsIAndroidBridge

Review of attachment 806704 [details] [diff] [review]:
-----------------------------------------------------------------

r=me with comments addressed

::: widget/android/AndroidBridge.cpp
@@ +1569,5 @@
> +                                   nsIHandlerApp * *aDefaultApp, bool *aSuccess,
> +                                   uint32_t *aHandlerCount, nsIHandlerApp * **aHandlersArray)
> +
> +{
> +    __android_log_print(ANDROID_LOG_INFO, "GeckoURL", "url: %s", NS_ConvertUTF16toUTF8(aURL).get());

Remove logging of URL, this is a privacy concern

@@ +1571,5 @@
> +
> +{
> +    __android_log_print(ANDROID_LOG_INFO, "GeckoURL", "url: %s", NS_ConvertUTF16toUTF8(aURL).get());
> +    nsresult rv;
> +    nsCOMPtr<nsIMutableArray> handlers = do_CreateInstance(NS_ARRAY_CONTRACTID, &rv);

We should check rv here

@@ +1581,5 @@
> +    handlers->GetLength(&handlerCount);
> +    *aHandlersArray = new nsIHandlerApp*[handlerCount];
> +    for (uint32_t i = 0; i < handlerCount; i++) {
> +        rv = handlers->QueryElementAt(i, nsIHandlerApp::GetIID(),
> +                                   (void**)(*aHandlersArray + i));

Do we need to check rv here? If not then there's no point even assigning it here.

Comment 18

[Wesley Johnston (:wesj)]

Comment on attachment 806823 [details] [diff] [review]
patch to give option of passing a URI to a helper app

Review of attachment 806823 [details] [diff] [review]:
-----------------------------------------------------------------

Needs some cleanup, and better strings before it lands, but the code looks fine.

::: mobile/android/components/HelperAppDialog.js
@@ +28,5 @@
> +    let bundle = Services.strings.createBundle("chrome://browser/locale/browser.properties");
> +    var p = new Prompt({
> +      title: bundle.GetStringFromName("helperApp.pick")
> +    });
> +    var handlerOptions = [{

let here and above.

@@ +32,5 @@
> +    var handlerOptions = [{
> +      label: bundle.GetStringFromName("helperApp.saveToDisk"),
> +      handler: null
> +    }];
> +    let defaultHandler = new Object();

{} instead of 'new Object();'

@@ +34,5 @@
> +      handler: null
> +    }];
> +    let defaultHandler = new Object();
> +    let handlers = Services.androidBridge.getHandlersForURI(aLauncher.source.spec, "", defaultHandler);
> +    handlers.forEach(function(handler) {

If you wanted to be slightly fancier here, you could do something like:

handlerOptions.concat(handlers.map(function(handler) {
  return {
    label: handler.name,
    handler: handler,
    selected: (handler == defaultHandler)
  }
}));

@@ +53,5 @@
> +
> +    // Spin this thread while we wait for a result
> +    let thread = Services.tm.currentThread;
> +    while (retval == null)
> +      thread.processNextEvent(true);

Insert a blank line here.

@@ +54,5 @@
> +    // Spin this thread while we wait for a result
> +    let thread = Services.tm.currentThread;
> +    while (retval == null)
> +      thread.processNextEvent(true);
> +    if (retval.button == 0) {

A slightly safer version of this would be. (i.e. changing the order of the list won't break):

if (handlerOptions[retval.button].handler) {
  // call the handler
} else {
  // download
}

@@ +58,5 @@
> +    if (retval.button == 0) {
> +      aLauncher.MIMEInfo.preferredAction = Ci.nsIMIMEInfo.saveToDisk;
> +      aLauncher.saveToDisk(null, false);
> +    } else {
> +      aLauncher.MIMEInfo.preferredAction = Ci.nsIMIMEInfo.useHelperApp;

I still think we probably need to cancel the download here.

::: mobile/android/locales/en-US/chrome/browser.properties
@@ +291,5 @@
>  
>  #Open in App
>  openInApp.pageAction = Open in App
> +
> +helperApp.pick = What do you want to do?

This string feels a bit... out of place for us. Maybe we can just show the filename. Also we'd typically name the field something like "helperAppDialog.title" to give some context of where its shown to localizers.

@@ +292,5 @@
>  #Open in App
>  openInApp.pageAction = Open in App
> +
> +helperApp.pick = What do you want to do?
> +helperApp.saveToDisk = Save to disk
\ No newline at end of file

'to disk' also feels a bit technical. "Save"?

Comment 19

[Ian Barlow (:ibarlow)]

Per our discussion, I would suggest making this look like the other Android intents menus. It's a somewhat more expected UI to see for a choice like this. http://cl.ly/image/0p0l46213C1g

Comment 20

[Wesley Johnston (:wesj)]

Attachment: Move HelperApps to a jsm

This moves HelperApps.js to a jsm module. Rips the UI specific parts of it out into the (already existent) ExternalApps object. And (yeah I know, too much), cleans it up a bit, including adding a prompt method. Relies on bug 920170 for the prompt.

Comment 21

[Wesley Johnston (:wesj)]

Attachment: Patch 2/2 - Use HelperApps.jsm in HelperAppDialog

This uses HelperApps.jsm to do something pretty similar to what brad was doing.

Comment 22

[Wesley Johnston (:wesj)]

Attachment: Screenshot

This needs the buttons added from ian's mockups. I'm still trying to figure out the best way to fit them into Prompt.java and PromptInput.java's interaction. I decided that I'd save that for at least a separate patch.

Comment 23

[Mark Finkle (:mfinkle) (use needinfo?)]

Comment on attachment 810780 [details] [diff] [review]
Move HelperApps to a jsm

>diff --git a/mobile/android/chrome/content/browser.js

>+  _setForUri: function _setForUri(uri, apps) {

Rename to _setUriForPageAction, so we are more explicit about what the method is about to do

>diff --git a/mobile/android/chrome/content/HelperApps.js b/mobile/android/modules/HelperApps.jsm

>+const Cc = Components.classes;
>+const Ci = Components.interfaces;
>+const Cu = Components.utils;
>+const Cr = Components.results;

Can we use the new, cool way?

const { classes: Cc, interfaces: Ci, utils: Cu, results: Cr } = Components;

>+Cu.import("resource://gre/modules/XPCOMUtils.jsm");
>+Components.utils.import("resource://gre/modules/Services.jsm");
>+Components.utils.import("resource://gre/modules/Prompt.jsm");

Use Cu

>+  prompt: function showPicker(apps, promptOptions) {
>+    var p = new Prompt(promptOptions).addIconGrid({ items: apps });

var -> let

>+  getAppsForProtocol: function getAppsForProtocol(scheme) {

>+    var results = {};

var -> let

>+    for (var i = 0; i < protoHandlers.length; i++) {

var -> let

Comment 24

[Mark Finkle (:mfinkle) (use needinfo?)]

Comment on attachment 810781 [details] [diff] [review]
Patch 2/2 - Use HelperApps.jsm in HelperAppDialog

>diff --git a/mobile/android/locales/en-US/chrome/browser.properties b/mobile/android/locales/en-US/chrome/browser.properties

> helperapps.pick=Complete action using
> helperapps.saveToDisk=Download
>+helperapps.pick=Complete action using
>+helperapps.saveToDisk=Download

Remove the dups (I think you're just testing me)

Comment 25

[Wesley Johnston (:wesj)]

Attachment: Patch 1/3

Forgot to add the "Always" and "Just once" buttons here. But while I was doing it I wondered why I wrote the HelperApps.prompt method to be synchronous. This undoes that.

Comment 26

[Wesley Johnston (:wesj)]

Attachment: Patch 2/3

Update the ExternalsApps code to the new API (and add a button). This makes the little Android icon

1.) Show the prompt if its got multiple options. Its useful here because it can filter out HTTP handlers.
2.) Show an Ok button on the prompt so that you can close it. I'd like to remove that and just make clicking close the dialog. Lets do that somewhere else though.

Comment 27

[Wesley Johnston (:wesj)]

Attachment: Patch 3/3 - Make the HelperAppDialog also show button

This adds always/just now buttons to the Helper Apps dialog. It also supports setting a pref if you select always.

Comment 28

[Mark Finkle (:mfinkle) (use needinfo?)]

Comment on attachment 818141 [details] [diff] [review]
Patch 2/3

>diff --git a/mobile/android/chrome/content/browser.js b/mobile/android/chrome/content/browser.js

>     this._pageActionId = NativeWindow.pageactions.add({

>+          HelperApps.prompt(apps, {
>+            title: Strings.browser.GetStringFromName("openInApp.pageAction"),
>+            buttons: [
>+              Strings.browser.GetStringFromName("openInApp.ok")
>+            ]

Shouldn't we add the "Cancel" button too?

>diff --git a/mobile/android/locales/en-US/chrome/browser.properties b/mobile/android/locales/en-US/chrome/browser.properties

>+helperapps.alwaysUse=Always
>+helperapps.useJustOnce=Just once

These are not used in this patch. They are used in the next patch. You should move them just in case the patches land in weird ways.

>+openInApp.ok = Ok

Ok -> OK

r- to get the "Cancel" button. And we should get Ian to approve a screenshot.

Comment 29

[Mark Finkle (:mfinkle) (use needinfo?)]

Comment on attachment 818143 [details] [diff] [review]
Patch 3/3 - Make the HelperAppDialog also show button

>diff --git a/mobile/android/components/HelperAppDialog.js b/mobile/android/components/HelperAppDialog.js

>+      if (data.button == 0) {
>+        this._setPref(aLauncher, apps[data.icongrid0]);
>+      }
>+      });

Indent the "if" block

>+  _getPrefName: function getPrefName(mimetype) {
>+    return "browser.download." + mimetype.replace("\\", ".");

We hang a lot of prefs directly off of "browser.download." so let's use "browser.download.preferred."

But I wonder if we should be using the Launcher's preferredApplicationHandler settings?

>+  _getPref: function getPref(launcher) {

_getPref -> _getPreferredApp

>+  _setPref: function _setPref(launcher, app) {

_setPref -> _setPreferredApp


r+ with the nits fixed and move the strings into this patch, but think about why we shouldn't use the HandlerApp's system for remembering preferred apps

Comment 30

[Wesley Johnston (:wesj)]

(In reply to Mark Finkle (:mfinkle) from comment #28)
> r- to get the "Cancel" button. And we should get Ian to approve a screenshot.

Yeah. I was actually avoiding this because we're not including "Cancel" on the other dialog. We also don't include it in the crash reporter dialog either. And I've seen a few random Google apps not include it at times either (Calendar in particular). Instead, they just back to exit the dialog. I've kinda grown to like the idea of reducing some clutter by removing it.

But digging around, a lot of apps (most) DO include it all the time. And its in screenshots for Android's UX guidelines [1]. Probably better to include it and avoid confusing users.

https://developer.android.com/design/patterns/confirming-acknowledging.html

Comment 31

[Wesley Johnston (:wesj)]

Attachment: Patch 2/3

Fixup. Also, there's a screenshot of this at:

http://dl.dropboxusercontent.com/u/72157/intents.png

I think the blue highlight needs tweaking :)

Comment 32

[Wesley Johnston (:wesj)]

Also, our preffered application handler stuff comes from Android itself [1] (incorrectly right now, filing...). There USED to be interfaces to request something be made the preferred handler in PackageManager. They've all been deprecated at this point :( So I need to fix getting the handler, but with these custom dialogs, we can't set the preferred handler.

Maybe these pref should be handled by HelperApps.jsm instead (with an optional prefix so that we can have separate behaviour in different boxes?).

[1] http://mxr.mozilla.org/mozilla-central/source/uriloader/exthandler/android/nsMIMEInfoAndroid.cpp#52

Comment 33

[Ian Barlow (:ibarlow)]

(In reply to Wesley Johnston (:wesj) from comment #31)
> Created attachment 818529 [details] [diff] [review]
> Patch 2/3
> 
> Fixup. Also, there's a screenshot of this at:
> 
> http://dl.dropboxusercontent.com/u/72157/intents.png
> 
> I think the blue highlight needs tweaking :)

It looks like just removing the border should do it.

Comment 34

[Mark Finkle (:mfinkle) (use needinfo?)]

Comment on attachment 818529 [details] [diff] [review]
Patch 2/3

Wait. This is the wrong patch. This is Patch 1/3.

Comment 35

[Wesley Johnston (:wesj)]

Attachment: Patch 2/3

Whoops. Thanks. This handles the page action.

Comment 36

[Wesley Johnston (:wesj)]

Attachment: Patch 3/3 - Make the HelperAppDialog also show buttons

Comment 37

[Wesley Johnston (:wesj)]

Attachment: Patch 4/3 - Make the HelperAppDialog also show buttons

My brian is obivoulsy not working right now. Here's the right patch here. The other one updates the icons to not have a border. Fixing...

Comment 38

[Mark Finkle (:mfinkle) (use needinfo?)]

Comment on attachment 818686 [details] [diff] [review]
Patch 3/3 - Make the HelperAppDialog also show buttons

I assume this is the wrong patch. Obsolete?

Comment 39

[Wesley Johnston (:wesj)]

Attachment: Patch 3/3 - Update graphics

Yeah. You beat me to finishing the upload :) This just removes the bright border. 

http://dl.dropboxusercontent.com/u/72157/intentchooser.png

Comment 40

[Mark Finkle (:mfinkle) (use needinfo?)]

Comment on attachment 818686 [details] [diff] [review]
Patch 3/3 - Make the HelperAppDialog also show buttons

Obsoleting this one

Comment 41

[Ian Barlow (:ibarlow)]

(In reply to Wesley Johnston (:wesj) from comment #39)
> Created attachment 818706 [details] [diff] [review]
> Patch 3/3 - Update graphics
> 
> Yeah. You beat me to finishing the upload :) This just removes the bright
> border. 
> 
> http://dl.dropboxusercontent.com/u/72157/intentchooser.png

Looks great Wes. Ship er :)

Comment 42

[Wesley Johnston (:wesj)]

Folded and landed:
https://hg.mozilla.org/integration/fx-team/rev/0cc4a019835f

Comment 43

[Wesley Johnston (:wesj)]

https://hg.mozilla.org/integration/fx-team/rev/aec9897dc66d

Comment 44

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/0cc4a019835f
https://hg.mozilla.org/mozilla-central/rev/aec9897dc66d

Comment 45

[Frank Wein [:mcsmurf]]

Attachment: Bug with the new feature?

I've tried to verify the fix, but not sure if this now works as expected as the UI does not work at all on some test page with an m3u8 file: I went to http://www.tagesschau.de/multimedia/livestreams/livestream-eins100.html and clicked on the Play button with a 2013-10-20 nightly build. Then I get the result in the screenshot. I get two options: Download the file or use the app "Filme" ("Movies" in English, some app from Sony). And at this point I'm stuck. I've tried to tap on an option/app, tap and hold on an app, nothing happens. I've also now installed "MX Player" as I was not sure if "Filme" can actually open m3u8 files (MX Player should be able to). But nothing changed. I'm a bit puzzled how this UI should work, a bug?

Comment 46

[Frank Wein [:mcsmurf]]

To make testing easier: It opens this m3u8 file when tapping on the play icon: http://tagesschau-lh.akamaihd.net/i/tagesschau_1@119231/master.m3u8 (not sure if this is a stable URL or just something that changes every few days; it's a live stream from a German TV program)

Comment 47

[Brad Lassey [:blassey] (use needinfo?)]

Comment on attachment 819651 [details]
Bug with the new feature?

this looks as expected.

Comment 48

[Frank Wein [:mcsmurf]]

I've attached a Firefox (remote) debugger to the main process, in the Console (with Net/CSS/JS/Security/Logging enabled) it says when tapping on the play icon on that page:
[16:54:09.377] Sending: {"type":"Intent:GetHandlers","mime":"application/vnd.apple.mpegurl","action":"","url":"http://tagesschau-lh.akamaihd.net/i/tagesschau_1@119231/master.m3u8","packageName":"","className":""}
[16:54:09.395] Unexpected selection from grid: undefined

No further log messages appear when tapping on any icon/app in the UI from the screenshot. Maybe I should file a new bug about this issue?

Comment 49

[Frank Wein [:mcsmurf]]

I forgot the
[16:54:06.288] GET http://tagesschau-lh.akamaihd.net/i/tagesschau_1@119231/master.m3u8 [HTTP/1.1 200 OK 635ms]
part of the log.. (appears before the "Sending: " part).

Comment 50

[Wesley Johnston (:wesj)]

Yeah. Tree was closed during my first push. I tried a new trick to reapply and push and apparently lost this bit. Thanks. Pushing :)

Comment 51

[Wesley Johnston (:wesj)]

https://hg.mozilla.org/integration/fx-team/rev/04f77c1e3337

thanks for testing :)

Comment 52

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/04f77c1e3337

Comment 53

[Aaron Train [:aaronmt]]

Did everything land here? This is more or less not entirely working for me, see dependancy.

Comment 54

[Wesley Johnston (:wesj)]

The link at http://qthttp.apple.com.edgesuite.net/1010qwoeiuryfg/0150_vod.m3u8 works fine for me on nightly, but you're right the ones in bug 929488 have trouble loading.

Comment 55

[henryfhchan]

>+    63       app.launch(aLauncher.source);
>     64       if (!app.launch(aLauncher.source)) {

doesn't this launch the app twice?

Comment 56

[Hallvord R. M. Steen [:hallvors]]

Attachment: 780379.htm - demo of VIDEO element linked to M3U8, directly from Apple docs

Demo code found on
https://developer.apple.com/library/ios/documentation/networkinginternet/conceptual/streamingmediaguide/DeployingHTTPLiveStreaming/DeployingHTTPLiveStreaming.html

Comment 57

[Hallvord R. M. Steen [:hallvors]]

This bug doesn't seem a suitable place for handling <video src="foo.m3u8">, so I've filed bug 941351. Will move the dependencies there.

Comment 58

[(not reading bugmail) Nick Desaulniers [:\n]]

As a heads up, m3u8 is an extended playlist file.  There's no need for a media element to have to handle these natively; playlist files can be parsed in JavaScript and fed 1 by 1 to a media element.  See: https://github.com/nickdesaulniers/javascript-playlist-parser

Comment 59

[(not reading bugmail) Nick Desaulniers [:\n]]

Further, m3u8 is possibly the stupidest of playlist types; playlist files such as m3u were used before we had nice file containers that had metadata; the playlist file was used for adding metadata when the container did not allow for it.  But parsing metadata from the container is pretty easy nowadays; ffmpeg can be used server-side to parse this information.

Comment 60

[Hallvord R. M. Steen [:hallvors]]

Nick: that's interesting, thanks! I suppose it might be a quick fix to bug 941351 (if there isn't more Apple-specific things in the way the video itself works) to add some JS like yours to run the <video> element? I suppose it would need to run in chrome to make sure we do not run into cross-domain issues.

Comment 61

[(not reading bugmail) Nick Desaulniers [:\n]]

> I suppose it would need to run in chrome to make sure we do not run into cross-domain issues.

Indeed, the biggest challenge with supporting playlist files is not the assets they refer to, as the src attribute of a media element my be cross origin (not sure about cross protocol ie. mixed content), but with fetching the playlist file cross origin as text/plain to parse.

Now, I had first stumbled upon this bug as the weekly meeting mentioned support for HLS, or HTTP Live Streaming, which is something that I find very interesting.  If we could make Firefox support the HLS protocol as the client, like we did recently with the ICY protocol (also extensively used for streaming audio), now that would be interesting.

Comment 62

[Cristina Madaras, QA [:CristinaM]]

Verified as fixed in builds:
32.0a1 (2014-06-04)
31.0a2 (2014-06-04)
30.0b10
29
Device: Galaxy Nexus (Android 4.2.1)

Notes: I used http://qthttp.apple.com.edgesuite.net/1010qwoeiuryfg/0150_vod.m3u8