Closed Bug 498523 Opened 15 years ago Closed 8 years ago

Invoke external handler when media.ogg.enabled=false

Categories

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

Product:
Core
Component:
Audio/Video: Playback
Platform:
x86
All
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: wodny, Unassigned)

References

Details

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
Component: General → Video/Audio
Product: Firefox → Core
QA Contact: general → video.audio
Version: unspecified → 1.9.1 Branch
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>.
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.
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.
FWIW, bug 449358 covers the default controls not working when script is disabled.
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.
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?
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.
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.
OS: Linux → All
Summary: HTML5 <video> and <audio> tags to execute external ogg player → Invoke external handler when media.ogg.enabled=false
Version: 1.9.1 Branch → Trunk
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.
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.
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
It's a sad message.

Now I will have to deal with critical security bugs both for internal player and mplayer.
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?
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.
(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.
(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.
(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.
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.
(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.
(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.
Roger.

A quick option under the context menu "enable Ogg for this element" would also be quite nice :-)
Component: Audio/Video → Audio/Video: Playback
It seems unlikely that we'll do this at this point in time.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.