317569 - Don't let plugins take over the context menu - give them only sub-menu

Status: RESOLVED WONTFIX

(Core Graveyard :: Plug-ins, enhancement, P5)

Description

[Pgr]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.7.12) Gecko/20050915 Firefox/1.0.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.7.12) Gecko/20050915 Firefox/1.0.7

This discussion started on this mozillazine post (if not before...):
http://forums.mozillazine.org/viewtopic.php?t=286903&

The idea is that objects inside HTML pages, like Flash objects, etc., should not be allowed to handle all the context-menu (when a user right-clicks on them), but only a sub-menu of the context menu, so that regular context-menu actions are still available.

Reproducible: Always

Steps to Reproduce:
1. Go to a page with object content (like Flash objects) - example: http://www.macromedia.com
2. Right-Click an object
OR 
2.try to start a mouse gesture with the right-button
Actual Results:  
You get an object-specific menu, and lament the fact that all the other options aren't there
OR
You get a menu, not a mouse-gesture trail. You have to look for a non-object space in the page in order to really be able to do the gesture... on some pages, there is very little of this space...

Expected Results:  
I say put that object menu as a submenu. If you right-click on a flash object, you would get a menu with something like:

Back
Reload
Object ---> Play
            Loop
            About Macromedia Flash Player 7.0
            etc.
Save object as...
View page source
etc.

You get the point: the usual commands plus a submenu with the objects' commands. 

I think this is in line with the FF philosophy of giving the web back to the user, not letting page content take away your legitimate options.

It's also good object-oriented philosophy: a flash object (or any other object) is not the top of the object hierarchy: it's a flash object (with specific actions like "Loop"), but it's also a part of an HTML page (with its own actions like "View Source"), and it's part of a browser application (with its own actions like "Back").

Remember end-users should not be (and typically are not) aware of the fact that parts of web pages are objects handled by plug-ins.

Completely different context-menu behaviour is confusing - there should be only marginal differences for different objects. Web-page actions like BACK should be available on ALL web pages (and all parts of them). Saving a flash .swf file should be as easy as selecting "Save As" from it's context menu.

It's also very annoying for mouse gesture users: and there are many thousands of them. And extension writers can't do anything about it because it's a core issue - they never get to see the right-click.

Correcting this would result, IMHO, in an overall better browser design, would enhance user control and be great news for mouse-gesture users.

Comment 1

[Matthias Versen [:Matti]]

You can send the mouse event to the plugin which paints a context menu and if you also use the event in the browser you get a context menu from the plugin and from the Browser (which would be wrong) or if you don't send a context menu to the plugin and you don't get a plugin context menu (also wrong).

The plugin itself paints the context menu (very easy to see) and it's impossible to integrate it in the browser context menu.

I think this is a wontfix

Comment 2

[Pgr]

(In reply to comment #1)
> The plugin itself paints the context menu (very easy to see) and it's
> impossible to integrate it in the browser context menu.

Thanks for your input, you seem to know more about this than me... I never thought that the plugin could draw the menu, because sometimes the menu extends beyond the borders of the plugin area...

But perhaps it's not impossible to integrate: after all, the plugin draws the menu at the coordinates passed to it by the browser. If the browser would draw its own menu, with an entry labeled "Plugin options >" and pass the plugin the coordinates that would make it draw an adjacent menu, at the same height of this entry, then it would basically look like an ordinary submenu.