Just FYI, the current implementation in Gecko also checks the shift key,
if it is pressed then custom context menu items won't show at all, just
the UA items.
On 02/07/14 14:36, 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. 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.
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 <d...@arandomurl.com> 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
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
