> Sent: Thursday, 10 July, 2014 6:45:14 PM
> Subject: Re: Intent to implement: Ability to surpress default contextmenu
> items
>
> On Wed, 9 Jul 2014, Jonas Sicking wrote:
> > >
> > > This has been suggested many times, but the reason it's not part of
> >
On Wed, 9 Jul 2014, Jonas Sicking wrote:
> >
> > This has been suggested many times, but the reason it's not part of
> > the standard is that it's user-hostile.
>
> This argument always comes up, but I don't think this is an entirely
> accurate statement.
>
> This is less user-hostile than the
Something like this is actually in the spec:
http://www.whatwg.org/specs/web-apps/current-work/multipage/interactive-elements.html#context-menus
" When the user clicks the disclosure triangle, such a user agent would
expand the context menu in place, to show the browser's own commands"
On 10/0
Le 10 juil. 2014 à 14:57, Jonas Sicking a écrit :
> Many website use this feature to replace the UA context menu with
> their own context menu implemented in HTML. The result is a context
> menu which is less accessible. It also results in that if the user
> uses UA features to *not* make the UA
On Wed, Jul 2, 2014 at 9:14 AM, Dao 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 wrote:
we are
looking to implement an optional attribute that allows authors to
disabl
On Mon, Jun 30, 2014 at 5:26 AM, Wesley Hardman wrote:
> Suppressing the contextmenu is extremely user-hostile (for some users).
> There is a reason I always run with dom.event.contextmenu.enabled set to
> false.
This option would continue to work and make us ignore the
chrome="disabled" attri
On Sat, Jun 28, 2014 at 9:30 PM, Ian Hickson wrote:
> On Sat, 28 Jun 2014, Dale Harvey wrote:
>>
>> Application developers have the ability to specify additional menuitems for
>> contextmenus via
>> http://www.whatwg.org/specs/web-apps/current-work/multipage/interactive-elements.html#context-menus
Google docs is a very good use case, In a previous job I implemented a web
based spreadsheet and we also had to implement our own contextmenu and
surpress the default because of the way that it conflicts.
Its a catch 22, applications will continue to hijack the default menu
unless the functionalit
On 2014-07-02, 4:16 PM, Dao wrote:
On 02.07.2014 20:51, Ehsan Akhgari wrote:
We can still show the UA
context menu if you hold down shift like we do today though.
What would be the equivalent to that on Firefox OS?
I don't think we have a similar way to do this in Firefox OS.
Cheers,
Ehsan
On 02.07.2014 20:51, Ehsan Akhgari wrote:
We can still show the UA
context menu if you hold down shift like we do today though.
What would be the equivalent to that on Firefox OS?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://li
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.
On 2014-07-02, 2:55 PM, Wesley Hardman wrote:
That doesn't work if you have Element Inspector installed
(https://addons.mozilla.org/en-US/firefox/addon/element-inspector/). It is
restart-less, so I suppose its easy to toggle on and off.
Add-ons which hijack our key bindings cause all sorts o
That doesn't work if you have Element Inspector installed
(https://addons.mozilla.org/en-US/firefox/addon/element-inspector/). It is
restart-less, so I suppose its easy to toggle on and off.
On 2014-07-02 14:49, Jan Varga wrote:
> Just FYI, the current implementation in Gecko also checks the sh
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'
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, ther
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 alw
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 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.
On 2014-07-02, 3:12 AM, Henri Sivonen wrote:
On Sun, Jun 29, 2014 at 4:53 AM, Dale Harvey 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 wou
On Sun, Jun 29, 2014 at 4:53 AM, Dale Harvey 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
Am Sonntag, 29. Juni 2014 03:53:21 UTC+2 schrieb Dale Harvey:
> however they are currently shown in addition to the default items, 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.
Please ta
Suppressing the contextmenu is extremely user-hostile (for some users). There
is a reason I always run with dom.event.contextmenu.enabled set to false.
If anything alters the existing context menu, make sure there is a pref to
disable it. Even the disclosure chevron would be annoying to me.
O
On Sat, 28 Jun 2014, Dale Harvey wrote:
>
> Application developers have the ability to specify additional menuitems for
> contextmenus via
> http://www.whatwg.org/specs/web-apps/current-work/multipage/interactive-elements.html#context-menus
> however they are currently shown in addition to the defa
Application developers have the ability to specify additional menuitems for
contextmenus via
http://www.whatwg.org/specs/web-apps/current-work/multipage/interactive-elements.html#context-menus
however they are currently shown in addition to the default items, we are
looking to implement an optional
23 matches
Mail list logo
