On 2014-07-02 14:51, Ehsan Akhgari wrote: > On 2014-07-02, 2:36 PM, Wesley Hardman wrote: >> The current context menu event does suffer from the same issue. If this is >> implemented, there at least needs to be a matching >> dom.event.contextmenu.showall preference to always show all menu items. >> >> I don't think this proposal is worse, but it isn't really better. With the >> current event, I always have to hit escape when I actually DO need to get to >> a custom context menu, but I can still get to both. With this proposal, I >> have to expand to get to the UA items. > > Hmm, not sure what you mean by expanding... We can still show the UA > context menu if you hold down shift like we do today though. This seems reasonable. Though it does conflict with Element Inspector. There should always be some method of reaching the UA menu without having to change anything.
By expanding, I was referring to Ian's suggestion earlier in the thread. I forgot that wasn't part of the original intent. > I would recommend that instead of letting the author prevent the user from > getting to the user's browser's commands, the browser instead simply hide > the browser commands behind a disclosure chevron, as in this example: > > http://www.whatwg.org/specs/web-apps/current-work/multipage/interactive-elements.html#dom-contextmenu > > > Personally whenever I am right clicking on something, it usually to > get to a UA option; rarely do I ever use the custom options (either > way). With this proposal, my most used options are further away. > > Is it perhaps because most web pages do not have a useful custom context > menu? Would you say the same thing about, let's say, Google Docs? The > Google Docs custom context menus seem like a great use case for this to me. Mostly. Google Docs is an exception, where I *would* want this. > > Cheers, > Ehsan > >> On 2014-07-02 11:30, Ehsan Akhgari wrote: >>> On 2014-07-02, 3:12 AM, Henri Sivonen wrote: >>>> On Sun, Jun 29, 2014 at 4:53 AM, Dale Harvey <[email protected]> wrote: >>>>> we are >>>>> looking to implement an optional attribute that allows authors to disable >>>>> the default context menu items so only the applications items are shown. >>>> >>>> I think we shouldn't do this, since it would be hostile to users. I >>>> think it would be OK to allow apps to request that the User >>>> Agent-provided context menu items be tucked away in a submenu, though. >>> >>> Note that this is something that web pages are already able to do. Do >>> you think the contextmenu event that we currently support suffers from >>> the same issue? Why is this proposal worse than that? >>> >>> Cheers, >>> Ehsan >>> >> >> _______________________________________________ >> dev-platform mailing list >> [email protected] >> https://lists.mozilla.org/listinfo/dev-platform >> > _______________________________________________ dev-platform mailing list [email protected] https://lists.mozilla.org/listinfo/dev-platform
