On Wed, Jul 2, 2014 at 9:14 AM, Dao <d...@design-noir.de> wrote: > On 02.07.2014 17: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? > > > It suffers from the same issue and does indeed annoy me as a user from time > to time (e.g. with youtube's html player). However, the spec at least allows > for bypassing this behavior: > > "User agents may provide means for bypassing the context menu processing > model, ensuring that the user can always access the UA's default context > menus. For example, the user agent could handle right-clicks that have the > Shift key depressed in such a way that it does not fire the contextmenu > event and instead always shows the default context menu."
We should definitely add the same language to this new feature. > Gecko supports dom.event.contextmenu.enabled to that end. It used to be a > visible preference in Firefox, but now it's merely a hidden one. And we should definitely make this pref ignore the chrome=disabled attribute. / Jonas _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform