Last Comment Bug 498523 - Invoke external handler when media.ogg.enabled=false
: Invoke external handler when media.ogg.enabled=false
Status: RESOLVED WONTFIX
:
Product: Core
Classification: Components
Component: Audio/Video: Playback (show other bugs)
: Trunk
: x86 All
: -- enhancement with 3 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
: 496551 506782 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-06-15 17:27 PDT by Marcin Szewczyk, Wodny
Modified: 2016-01-21 13:42 PST (History)
13 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Marcin Szewczyk, Wodny 2009-06-15 17:27:33 PDT
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.10) Gecko/2009042807 Iceweasel/3.0.9 (Debian-3.0.9-1)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.10) Gecko/2009042807 Iceweasel/3.0.9 (Debian-3.0.9-1)

I think it would be nice if a Firefox >=3.5 user wasn't forced to use the built-in ogg player. The end of all the variety of Flash players is great, but still I would like to be able to play ogg media in my mplayer without manually copying the link.

The media.ogg.enabled setting seams to disable <audio> and <video> tags completely. No external player set in Application helpers is executed.

Reproducible: Always

Steps to Reproduce:
1. Open a page with HTML5 <audio> or <video> tag
2.
3.
Actual Results:  
Internal player is executed (media.ogg.enabled = true).
Nothing happens (media.ogg.enabled = false)

Expected Results:  
Execution of Application helper when media.ogg.enabled = false
Comment 1 Boris Zbarsky [:bz] (Out June 25-July 6) 2009-06-16 08:02:14 PDT
Doing this for <video> would be pretty unreasonable, actually, since it would behave completely differently from an actual <video> (e.g. not composite with the web page).  Might make some sense for <audio>.
Comment 2 cajbir (:cajbir) 2009-06-16 08:05:47 PDT
It wouldn't make much sense for audio either since no events would be raised for timeupdate, seeking,etc so user controls in JS or synchronized actions on the page wouldn't run.
Comment 3 Marcin Szewczyk, Wodny 2009-06-16 10:53:11 PDT
There is no requirement that a browser should have scripting (JavaScript) enabled. Personally I use NoScript and JavaScript is used very rarely.

Furthermore, HTML5 Editor's Draft states:
"4.8.10.11 User interface. The controls attribute [...] If the attribute is present, or if scripting is disabled for the media element, then the user agent should expose a user interface to the user.".
So the HTML5 creators are quite aware of the fact not everybody uses scripting. The situation when Firefox launches external player (embeded or not) would give the same functionality as when scripting is disabled.
Comment 4 Justin Dolske [:Dolske] 2009-06-16 11:51:31 PDT
FWIW, bug 449358 covers the default controls not working when script is disabled.
Comment 5 Maik Musall 2009-07-25 04:29:03 PDT
I don't think that this behaviour is directly linked to HTML5 tags. I have a page with a submit button that responds with a Content-Type: application/ogg, and I cannot get FF 3.5 to save that file, as I could with FF 3.0. I always get the direct playback controls on a new page. Settings like Applications / application/ogg -> Save/Ask do not have any effect on that, which I consider to be the actual bug.

If I set media.ogg.enabled to false, nothing happens at all when the application/ogg file is received. It is simply dismissed.
Comment 6 Chris Pearce (:cpearce) 2009-07-26 15:46:20 PDT
So your problem is that you're loading an ogg video directly in firefox (e.g. NOT in a <video> tag in another document, but in a tab by itself) and you want it to be redirected to an external handler program when media.ogg.enabled=false?
Comment 7 Maik Musall 2009-07-27 05:48:44 PDT
It's actually ogg audio, not video. The website (not public, so I cannot provide a link for illustration) uses a submit button and the corresponding server action returns a page not of type text/html, but application/ogg.

Prior to FF 3.5, I got a dialog where I could choose either an app to handle the file or to save it. I currently have to be able to save the file.

The end user shouldn't be bothered with the media.ogg.enabled setting (at least not directly); the end user has a Preferences setting in the Applications section. There's an application/ogg entry, and when that's set to "always ask", I'd expect to be asked, of course.
Comment 8 Chris Pearce (:cpearce) 2009-07-27 16:30:09 PDT
Ok, so the issues here is:

Whether FF should ask the user when opening application/ogg in a tab by itself (or in an existing tab) whether it should play it, save it, or redirect it to external handler.

We need to handle this for either media.ogg.enabled=false or true (currently if  you open application/ogg directly, nothing happens).

Personally, I think we should have this behaviour:
* With media.ogg.enabled=true, play the ogg/video as we currently do.
* With media.ogg.enabled=false pop up the old invoke external handler/save dialog, as per the old behaviour.
Comment 9 Chris Pearce (:cpearce) 2009-07-27 16:30:19 PDT
*** Bug 506782 has been marked as a duplicate of this bug. ***
Comment 10 Chris Pearce (:cpearce) 2009-07-27 16:30:28 PDT
*** Bug 496551 has been marked as a duplicate of this bug. ***
Comment 11 Johannes 2009-07-27 16:35:15 PDT
I don't like the idea of having the playback linked to the same variable as <video> / <audio> embeds. There are already enough statements that cover my opinion, so I won't go into detail again.
Comment 12 Andrew Clover 2009-12-16 07:40:41 PST
Even when media.ogg.enabled is true, I would like the ability to get an ‘Always Ask’ dialogue when a link of type */ogg when followed. For every other type this is possible (even, curiously, WAV).

Ideally this should be configured from the normal Applications preference list in exactly the same way as you can choose whether to view RSS feeds directly in the browser from there.

Currently the OGG types are listed in the Applications list, but it makes no difference what setting you choose as it is always ignored and the inline player used instead.
Comment 13 alta88 2010-04-20 11:44:26 PDT
it seems pretty inconceivable that, for .og* links, an explicit user preference to open the content in an external app should be not respected, due to some hardcoding decisions (Bug 448603).  attempted capture a la '90s AOL is not a good idea.
Comment 14 Marcin Szewczyk, Wodny 2010-04-20 12:33:40 PDT
It's a sad message.

Now I will have to deal with critical security bugs both for internal player and mplayer.
Comment 15 cajbir (:cajbir) 2010-04-20 14:36:38 PDT
The don't think the external handler settings should be used for <video> or <audio> (even if ogg media support is disabled via setting).

I do agree that if Ogg support is disabled via the preference, or if an external handler is set up, then using <object> or directly accessing the video should use that external handler.

Is that the behaviour you are looking for in this bug?
Comment 16 Marcin Szewczyk, Wodny 2010-04-20 14:47:32 PDT
I would like to be able to play a media file from an <audio> or <video> tag in an external player in a comfortable way. It would be acceptable if a link was presented, instead of the media, so then I could click and use a defined helper.

The link should be generated by the browser, not a site's author.

This could be enabled only when Ogg support was disabled (codecs offline).

So it is the direct access part. I just wouldn't like to be forced to parse a page's source or inspect DOM to watch Ogg media in an external player.
Comment 17 cajbir (:cajbir) 2010-04-20 15:34:25 PDT
(In reply to comment #16)
> I would like to be able to play a media file from an <audio> or <video> tag in
> an external player in a comfortable way. 

There are no plans to implement this. The API requirements for <audio> and <video> are complex and I don't believe it would be possible to implement it using an external player.
Comment 18 alta88 2010-04-20 16:03:43 PDT
(In reply to comment #15)
> The don't think the external handler settings should be used for <video> or
> <audio> (even if ogg media support is disabled via setting).
> 

what possible reason could you have for forcing all users to view this content type within a browser page?

1)the biggest usage problem is loss of multitasking; instead of viewing content in an appropriately sized window, and perhaps continuing with browsing, the entire browsing flow must be stopped and dedicated to internal viewing without leaving the page.
2)thus, whatever properties are published along with the <video> tag are of no concern to the user.  a dedicated app will always be more flexible and richer in playback controls than the rendering within a page.  so some kind of tab tearoff window is out.
3)for links defined by href= or src= there is no case whatsoever for intercepting this load and bypassing a user's helper app prefs.

this 'locking in' of ogg content as internal to the browser is quite misguided and smacks of control issues.  ogg will succeed because it is unencumbered by patent and an opensource codec.  in fact, such artificial browser tie in will hurt, not help, its adoption.
Comment 19 Marcin Szewczyk, Wodny 2010-04-20 16:14:17 PDT
(In reply to comment #17)
> There are no plans to implement this. The API requirements for <audio> and
> <video> are complex and I don't believe it would be possible to implement it
> using an external player.

I don't want full API support. I want a simple method of executing an external player with source.src value as it's parameter.

I suppose it would be feasible even using GreaseMonkey if Fx would fallback to helpers after setting media.ogg.enabled to false. Now it just does nothing when it sees Ogg.
Comment 20 cajbir (:cajbir) 2010-04-20 16:18:13 PDT
The approach I outlined in comment 15 does not lock the user in. All videos
have a right click menu that allows the user to choose to 'View Video'. 

If we fix things so that the user can override the internal playback when
directly playing a video then choosing this menu item would display the video
in an external player. As far as I can tell this fits your use case. 

Please try to avoid discussions of promoting Ogg or attempts to 'control'
formats and codecs. They have nothing to do with why external players can't be
used to directly implement <video> or <audio>.

Remember that <video> and <audio> aren't just used for YouTube style playback.
They can, and often are, used for special effects, copying image data and
manipulating it to canvas, etc. A page won't behave correctly if video falls
back to an external player.
Comment 21 Marcin Szewczyk, Wodny 2010-04-20 16:27:33 PDT
(In reply to comment #20)
> The approach I outlined in comment 15 does not lock the user in. All videos
> have a right click menu that allows the user to choose to 'View Video'. 

After setting media.ogg.enabled to false View video and Copy Video Location are grayed out.
Comment 22 cajbir (:cajbir) 2010-04-20 16:28:47 PDT
(In reply to comment #21)
> After setting media.ogg.enabled to false View video and Copy Video Location are
> grayed out.

Part of fixing the 'allow external handlers to override internal player' issue would be to fix that too if this is the approach we wanted to take.
Comment 23 Marcin Szewczyk, Wodny 2010-04-20 16:32:19 PDT
Roger.

A quick option under the context menu "enable Ogg for this element" would also be quite nice :-)
Comment 24 Anthony Jones (:kentuckyfriedtakahe, :k17e) 2016-01-21 13:42:32 PST
It seems unlikely that we'll do this at this point in time.

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