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

Reply via email to