This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
This was was cloned from bug 12999 as part of operation LATER convergence. Originally filed: 2011-06-20 09:11:00 +0000 Original reporter: Jan Varga <jan.varga@gmail.com> ================================================================================ #0 Jan Varga 2011-06-20 09:11:20 +0000 -------------------------------------------------------------------------------- http://www.whatwg.org/specs/web-apps/current-work/multipage/interactive-elements.html#context-menus "The default action of this event is that the user agent must show a context menu built from the menu element. The user agent may also provide access to its default context menu, if any, with the context menu shown. For example, it could merge the menu items from the two menus together, or provide the page's context menu as a submenu of the default menu." So most of the time the default context menu will be shown along with page menu. Anyway, in some situations (especially for web apps), there is a need to not show the default context menu. For example http://userexperience.evantageconsulting.com/2010/08/detailed-html5-ux-designers/ (Figure 4) ================================================================================ #1 Tab Atkins Jr. 2011-06-20 17:41:58 +0000 -------------------------------------------------------------------------------- Hiding the default context menu is actively hostile to users. If I'm right-clicking, I expect the default options to still be accessible (for example, I might be trying to hit "Save As", "View Source", or "Inspect Element"). ================================================================================ #2 Jan Varga 2011-06-20 17:54:12 +0000 -------------------------------------------------------------------------------- It's mostly useful for web apps (see the link). Firefox implementation will respect this attribute only in app tabs. Anyway, shift right click will always show the default context menu (w/o page menu) Many web sites prevent access to default context menu anyway. ================================================================================ #3 Tab Atkins Jr. 2011-06-20 17:56:23 +0000 -------------------------------------------------------------------------------- (In reply to comment #2) > It's mostly useful for web apps (see the link). Firefox implementation will > respect this attribute only in app tabs. Yes, it makes them slightly prettier, at the cost of usability. Within app tabs it's not quite as big of a deal. > Anyway, shift right click will always show the default context menu (w/o page > menu) That's not at all discoverable. :/ > Many web sites prevent access to default context menu anyway. Which is actively hostile, and we should really turn off that functionality. ================================================================================ #4 Ian 'Hixie' Hickson 2011-06-21 07:26:30 +0000 -------------------------------------------------------------------------------- EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: The whole point here is to include the UA context menu instead of replacing it. ================================================================================ #5 Jonas Sicking 2011-07-14 04:58:54 +0000 -------------------------------------------------------------------------------- Has anyone talked to web-app developers which currently hide the context menu. IIRC several google apps does this, such as google docs and google maps. Are they replacing the existing context menu because they can't add to it? Or are they replacing it because that is what they want to do? ================================================================================ #6 Tab Atkins Jr. 2011-07-14 05:16:17 +0000 -------------------------------------------------------------------------------- (In reply to comment #5) > Has anyone talked to web-app developers which currently hide the context menu. > IIRC several google apps does this, such as google docs and google maps. Are > they replacing the existing context menu because they can't add to it? Or are > they replacing it because that is what they want to do? I don't care if they want to do it. I want them to *not* do it, because I want to always have access to the normal context menu. ================================================================================ #7 Jonas Sicking 2011-07-14 05:20:57 +0000 -------------------------------------------------------------------------------- So you're going to advocate that chrome removes support for the contextmenu event? Which sole purpose is to disable the built-in context menu? As long as that's supported both silly and counter productive to not allow the ability to disable the built-in context menu items. ================================================================================ #8 Tab Atkins Jr. 2011-07-14 05:26:50 +0000 -------------------------------------------------------------------------------- (In reply to comment #7) > So you're going to advocate that chrome removes support for the contextmenu > event? Which sole purpose is to disable the built-in context menu? As long as > that's supported both silly and counter productive to not allow the ability to > disable the built-in context menu items. Not necessarily. I do need to advocate for an alternate method that is guaranteed to summon the default context menu, as the spec recommends in a MAY. There are use-cases (largely game-related, I think) to disable the context menu popping up from a right-click. But if you're supplying your own context menu, I don't see a reason to require even that. A single option on the menu that summons the default context menu would suffice. ================================================================================ #10 Jonas Sicking 2011-08-22 20:16:39 +0000 -------------------------------------------------------------------------------- Tab: I don't quite understand what UI you are advocating for. What I'm saying is that pages currently use the contextmenu event + piles of <div>s in order to create their own context menu and remove the default one. The <menu> element provides an opportunity to create a better situation. By adding a @nodefault attribute, we allow websites to semantically describe that they want their context menu options to replace the default set of options. This gives UAs a lot more freedom in creating a good user experience than the current contextmenu event + piles of <div>. With a @nodefault attribute UAs can expose UI to temporarily or permanently ignore the @nodefault. For example UAs can have an option "allow sites to replace context menu" which chooses if @nodefault should be ignored or not. Or they can add a option at the bottom which exposes the default menu as a sub-menu. Or add an option which says "don't allow this website to replace my context menu". UAs could even choose to expose only a set of most critical options when @nodefault is set. Currently none of those things are possible. Could you describe what you are hoping or expecting will happen as long as we don't have @nodefault but still do have the context menu event? ================================================================================ #11 Jonas Sicking 2011-08-22 20:17:55 +0000 -------------------------------------------------------------------------------- Meant to reopen. As long as the context menu event exists, not having @nodefault produces a strictly worse user experience. ================================================================================ #12 Tab Atkins Jr. 2011-08-22 20:22:56 +0000 -------------------------------------------------------------------------------- (In reply to comment #10) > Tab: I don't quite understand what UI you are advocating for. ... > Or they can add a option at the > bottom which exposes the default menu as a sub-menu. The bit I carved out above is what I expect browsers to do. That seems an obvious and clear answer. If you're suggesting an attribute to switch between "just add it to the existing context menu" and the above, then I'm okay with that. I'd prefer a better name, though. ================================================================================ #13 Ian 'Hixie' Hickson 2011-08-23 05:30:53 +0000 -------------------------------------------------------------------------------- I think before we add this we should find out (by exposing the feature) whether authors so object to the native menu that they won't accept to coexist with it (and will instead continue to use <div>s) or if they in fact would be happy to coexist with it but today are simply incapable of doing so. Note that the spec doesn't require that the elements be merged inline. They could be hidden behind a single context menu item. The merged items could be a subset of the full menu. The UA menu could be entirely hidden unless the user had brought up the menu while holding the shift key down. The UA could be entirely hidden if the user brought up the menu with the right mouse button but shown if the user used two fingers when pressing on the multitouch right mouse button. Only in some of these scenarios does it even make sense to expose a control to the author about what to do. Unless and until we have a better understanding of what implementations converge on and what authors actually want, it's impossible IMHO to make an educated decision on how to support the proposal. ================================================================================ #14 Ian 'Hixie' Hickson 2011-09-21 23:07:45 +0000 -------------------------------------------------------------------------------- I am marking this this LATER so that we can re-examine it when we have more implementation experience. ================================================================================ #15 Eric Sh 2011-10-24 17:46:19 +0000 -------------------------------------------------------------------------------- I believe that authors would object to the native menu for the following reasons: 1. Web applications do not want the user feel like they are using a browser(see reason 2) 2. This is a major barrier between native applications and web applications - Authors feel that UA's limit them to always let the user know that he's using the browser and because of this they tend to use in-UA-java for native user experience without the user knowing they use a browser. ================================================================================ #16 Tab Atkins Jr. 2011-10-24 17:53:37 +0000 -------------------------------------------------------------------------------- (In reply to comment #15) > I believe that authors would object to the native menu for the following > reasons: > 1. Web applications do not want the user feel like they are using a browser(see > reason 2) > 2. This is a major barrier between native applications and web applications - > Authors feel that UA's limit them to always let the user know that he's using > the browser and because of this they tend to use in-UA-java for native user > experience without the user knowing they use a browser. This seems incorrect. Very few authors use Java on the web at all. ================================================================================ #17 Eric Sh 2011-10-30 18:21:53 +0000 -------------------------------------------------------------------------------- (In reply to comment #16) > This seems incorrect. Very few authors use Java on the web at all. You are right that very few use java, but it was an example most actually use Flex(Flash) for native-like controls - which also adds some items to the context menu. For example, in winows the bigger the context menu the more likely it is for it to flip(when it overflows the edges of the screen) so getting to the items added takes much more mouse movement and user annoyance. But if authors could only show their menu items then this would not happen. The same argument for having a lot of context menu items(either added by the author or by the browser). ================================================================================ #18 Jan Varga 2011-11-25 11:01:34 +0000 -------------------------------------------------------------------------------- http://hacks.mozilla.org/2011/11/html5-context-menus-in-firefox-screencast-and-code/ See the discussion about default context menu. As I mentioned, this is needed especially for web apps. ================================================================================