Intent to Implement: contextmenu attribute and <menu>

[sanjo...@samsung.com]

Primary eng (and PM) emails

sanjo...@samsung.com

Spec

http://www.whatwg.org/specs/web-apps/current-work/#context-menus

http://www.whatwg.org/specs/web-apps/current-work/#the-menu-element

Summary

Implement contextmenu attribute which gives a mechanism to specify custom context menu for a particular element. The value of the contextmenu attribute must be the ID of menu element with type popup.

Motivation

- Allow web developers to define custom context menu for an element.

- Context menus are handy on touch based devices where DnD conflicts with scrolling.

- This will give web apps a whole new dimension.

-  Firefox implements this. http://people.mozilla.org/~prouget/bugs/context-menu-test/test.html looks good on mobile FF. 

Compatibility Risk

Mozilla is currently shipping this.

Demo at 

http://people.mozilla.org/~prouget/bugs/context-menu-test/test.html

Ongoing technical constraints

None.

Will this feature be supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS and Android)?

Yes.

OWP launch tracking bug?

http://code.google.com/p/chromium/issues/detail?id=87553

https://bugs.webkit.org/show_bug.cgi?id=58454

Row on feature dashboard?

No

Requesting approval to ship?

No

[jan....@gmail.com]

Please note that the implementation in Firefox hasn't been updated to the latest spec yet.
https://bugzilla.mozilla.org/show_bug.cgi?id=897102

Jan

[Adam Barth]

I'm not sure how interested we should be in adding these sorts of features to the engine at this time.  From my perspective, it's more important that we focus on improving the performance of the engine.  It's not clear to me how this feature helps improve the performance of the mobile web.

Adam

[Peter Beverloo]

Making the Web Platform more appy by capabilities towards bridging the gap between the Web and native mobile operating systems is a goal for this year as well, so I'm not entirely comfortable with saying that every addition strictly needs to improve (mobile) performance.  Something which closes an important gap in capabilities and does not regress performance should be acceptable as well.  In this case, offering an alternative for customizing long-press menus without needing to attach touch handlers to the document sounds to me like it could address both.

The implementation in Firefox seems to work just fine, I like the demonstration on their demo page.  I wonder whether we'd allow developers to hide the default context menu options as well -- introducing four or more custom options could easily fill the screen.  The specification seems to allow UAs to decide on the exact user experience of the context menus.  Do you know what their experiences with the API are?

I have no strong feelings about whether we should support this feature or not, but it seems like a nice to have.  If the implementation can build on top of the context menu code we already have in Blink, it doesn't have to be too complicated either.

Peter

[Adam Barth]

I agree with you that this feature is a "nice to have," but I don't think we should be adding nice-to-have features to the engine at this time.  We have more pressing problems to solve, like offline and performance.  Once we're doing well on the must-have features, we can add more nice-to-have features.

Adam

[Dimitri Glazkov]

FWIW, my first reaction was different from Adam's. I immediately thought: what is the API that HTMLElement uses to open a context menu in response to the long-press? But hey, I am a layer guy :)

:DG<

[Ian Hickson]

On Tue, 4 Feb 2014, Dimitri Glazkov wrote:
>
> FWIW, my first reaction was different from Adam's. I immediately
> thought: what is the API that HTMLElement uses to open a context menu in
> response to the long-press? But hey, I am a layer guy :)

<div contextmenu="menuid"> ... </div>

<menu id="menuid" type=popup>
<menuitem label="Hello World" onclick="...">
</menu>

Long-pressing (or right-clicking) on the <div> now shows the "Hello World"
item, either in place of, or in addition to, the UA menu (that's up to the
UA -- probably in place of, with a UI affordance for getting to the
default menu if the user needs it).

--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'

[Dimitri Glazkov]

On Tue, Feb 4, 2014 at 12:54 PM, Ian Hickson <i...@hixie.ch> wrote:

On Tue, 4 Feb 2014, Dimitri Glazkov wrote:
>
> FWIW, my first reaction was different from Adam's. I immediately
> thought: what is the API that HTMLElement uses to open a context menu in
> response to the long-press? But hey, I am a layer guy :)

<div contextmenu="menuid"> ... </div>

<menu id="menuid" type=popup>
  <menuitem label="Hello World" onclick="...">
</menu>

Long-pressing (or right-clicking) on the <div> now shows the "Hello World"
item, either in place of, or in addition to, the UA menu (that's up to the
UA -- probably in place of, with a UI affordance for getting to the
default menu if the user needs it).

Yup. So if I were to build this as a custom element, I check for the presence/value of the "contextmenu" attribute and then what happens? I guess what I am driving at is that opening and populating a context menu seems like a lower-layer API than HTML. <menu> and "contextmenu" are just convenient sugar around that.

... and yes, I know it's a bit of a trick question, since opening a context menu imperatively is a hard security problem that we'll probably never solve :-\

:DG<

[Ian Hickson]

On Tue, 4 Feb 2014, Dimitri Glazkov wrote:
> On Tue, Feb 4, 2014 at 12:54 PM, Ian Hickson <i...@hixie.ch> wrote:
> > On Tue, 4 Feb 2014, Dimitri Glazkov wrote:
> > >
> > > FWIW, my first reaction was different from Adam's. I immediately
> > > thought: what is the API that HTMLElement uses to open a context
> > > menu in response to the long-press? But hey, I am a layer guy :)
> >
> > <div contextmenu="menuid"> ... </div>
> >
> > <menu id="menuid" type=popup>
> > <menuitem label="Hello World" onclick="...">
> > </menu>
> >
> > Long-pressing (or right-clicking) on the <div> now shows the "Hello
> > World" item, either in place of, or in addition to, the UA menu
> > (that's up to the UA -- probably in place of, with a UI affordance for
> > getting to the default menu if the user needs it).
>
> Yup. So if I were to build this as a custom element, I check for the
> presence/value of the "contextmenu" attribute and then what happens?

You put a contextmenu="" in your shadow tree, pointing to the same <menu>,
presumably (I don't know how you make IDs point to the Document shadow
tree... how are you solving this for e.g. SVG gradients or custom form
controls participating in <form> handling?).

[TAMURA, Kent]

IMO, we should not implement <menu type=popup>.  Context menu is a bad UI, especially on mobile platforms and Mac.

--
TAMURA Kent
Software Engineer, Google

[Ian Hickson]

On Fri, 21 Feb 2014, TAMURA, Kent wrote:
>
> IMO, we should not implement <menu type=popup>. Context menu is a bad
> UI, especially on mobile platforms and Mac.

FWIW, context menus are triggered by contextmenu="". There is another way
that <menu type=popup> is used, which is via <button menu="">. These are
very common on mobile (especially Android) and increasingly common on Mac.

HTH,

[Si Robertson]

File IO. Web Audio. Web MIDI. Web RTC. Gamepad. Pointer Lock. Fullscreen. Custom Elements ... etc.

None of those APIs improve performance they enhance user/developer experience (if used correctly) and custom context menus will do the same thing. Despite that, the fact that Mozilla have already pushed custom context menus into Firefox should be reason enough for you guys to get this functionality into Chrome sooner rather than later.

Just my humble opinion :-)

[Adam Barth]

My concern is more about platform layering.  IMHO, context menus are better implemented at the framework level than baked into the platform, especially on mobile.  For example, it's not possible to implement fullscreen at the framework level because fullscreen lets the web page draw outside of its normal bounds.

Adam

[Ian Hickson]

On Thu, 10 Apr 2014, Adam Barth wrote:
>
> My concern is more about platform layering. IMHO, context menus are
> better implemented at the framework level than baked into the platform,
> especially on mobile. For example, it's not possible to implement
> fullscreen at the framework level because fullscreen lets the web page
> draw outside of its normal bounds.

Context menus can't be implemented at the framework level either, if
they're implemented in a way that integrates with the native context menus
of the platform (which is the purpose of <menu>).

[Adam Barth]

That's true on desktop, but it's much less true on mobile.  In android.View, for example, a context menu is just a normal Java class that you can implement yourself.

Adam

[Ian Hickson]

On Thu, 10 Apr 2014, Adam Barth wrote:
> > Context menus can't be implemented at the framework level either, if
> > they're implemented in a way that integrates with the native context menus
> > of the platform (which is the purpose of <menu>).
>

> That's true on desktop, but it's much less true on mobile. In
> android.View, for example, a context menu is just a normal Java class
> that you can implement yourself.

Sure. The Web exists on both, though.

[Adam Barth]

On Apr 10, 2014 12:37 PM, "Ian Hickson" <i...@hixie.ch> wrote:
>
>
> On Thu, 10 Apr 2014, Adam Barth wrote:
> > > Context menus can't be implemented at the framework level either, if
> > > they're implemented in a way that integrates with the native context menus
> > > of the platform (which is the purpose of <menu>).
> >
> > That's true on desktop, but it's much less true on mobile.  In
> > android.View, for example, a context menu is just a normal Java class
> > that you can implement yourself.
>
> Sure. The Web exists on both, though.

We're vastly more interested in investing in making the mobile web a compelling platform for developers than in making marginal improvements on desktop.

Adam

[Ian Hickson]

You misunderstand my argument. I'm not saying that Chrome should implement
<menu> at this time; I completely agree that a focus on mobile is critical
and that that implies that <menu> should not be implemented at this time.

The argument that we should not implement <menu> because it's not critical
for mobile, however, is different than the argument that we should not
implement <menu> because it is unnecessary since it can be implemented
using <div>s and CSS. The latter argument is not valid because while it is
true on mobile, mobile is not the only platform that the Web caters for,
and on non-mobile platforms, context menus cannot be adequately
implemented in that way.

[Jeffrey Yasskin]

I suspect you and Ian meant different things by "framework". Clearly
Chrome can implement contextmenu on Android, but jQuery couldn't
because at least 3 items in the native mobile context menu (open in
incognito, copy link text, and copy link address) are privileged
operations not available to javascript.

[Adam Barth]

On Thu Apr 10 2014 at 1:47:13 PM, Jeffrey Yasskin <jyas...@chromium.org> wrote:

I suspect you and Ian meant different things by "framework". Clearly
Chrome can implement contextmenu on Android, but jQuery couldn't
because at least 3 items in the native mobile context menu (open in
incognito, copy link text, and copy link address) are privileged
operations not available to javascript.

When I get a context menu in a Java-based Android application, I don't see those options.  Why should I see them in a Web-based Android application?

Adam

[Ian Hickson]

On Thu, 10 Apr 2014, Jeffrey Yasskin wrote:
>
> I suspect you and Ian meant different things by "framework". Clearly
> Chrome can implement contextmenu on Android, but jQuery couldn't because
> at least 3 items in the native mobile context menu (open in incognito,
> copy link text, and copy link address) are privileged operations not
> available to javascript.

I was assuming there were no such items on the mobile platforms Adam was
referring to.

It's true that even on some mobile platforms, frameworks can't implement
context menus. This does increase the rationale for supporting this
feature sooner rather than later.

[Ian Hickson]

On Thu, 10 Apr 2014, Adam Barth wrote:
> On Thu Apr 10 2014 at 1:47:13 PM, Jeffrey Yasskin <jyas...@chromium.org>
> wrote:
> >
> > I suspect you and Ian meant different things by "framework". Clearly
> > Chrome can implement contextmenu on Android, but jQuery couldn't
> > because at least 3 items in the native mobile context menu (open in
> > incognito, copy link text, and copy link address) are privileged
> > operations not available to javascript.
>
> When I get a context menu in a Java-based Android application, I don't
> see those options. Why should I see them in a Web-based Android
> application?

So that you can copy the link text or link address, presumably.

[Jeffrey Yasskin]

On Thu, Apr 10, 2014 at 1:51 PM, Adam Barth <aba...@google.com> wrote:
> On Thu Apr 10 2014 at 1:47:13 PM, Jeffrey Yasskin <jyas...@chromium.org>
> wrote:
>>
>> I suspect you and Ian meant different things by "framework". Clearly
>> Chrome can implement contextmenu on Android, but jQuery couldn't
>> because at least 3 items in the native mobile context menu (open in
>> incognito, copy link text, and copy link address) are privileged
>> operations not available to javascript.
>
>
> When I get a context menu in a Java-based Android application, I don't see
> those options. Why should I see them in a Web-based Android application?

What Ian said. I do agree that a web-based Android application
shouldn't be forced to show those entries, but I don't see a reason to
prevent it either. Android has some other long-press menus too:
"Paste" on input fields, and the "select-all, copy, share" toolbar
that appears over text. Apps should be able to add long-press items
while still giving users access to those existing commands. I'm not
certain that 'contextmenu' is exactly the right way to do this, but I
think the overall ability is actually somewhat important for mobile
apps.

Jeffrey

[Elliott Sprehn]

I agree with this. I do think we should implement some kind of <menu> feature otherwise web apps are at a disadvantage to native apps because they can't add actions to the menu without replacing the entire menu and losing the OS level actions (which also vary by phone and OS).

- E

[Adam Barth]

Ok, it seems like I'm in the minority on this topic.  I withdraw my objection.

Adam

[Dimitri Glazkov]

If we do, can we please layer it as JS API, rather than an HTML element? One can always build a <menu> element on top of that.

:DG<

[PhistucK]

Unless I am misunderstanding, specifying <menu label="Submit" command="some-id-of-an-input-type-submit"> can submit a form in a user agent, even if that user agent does not support JavaScript (or have it disabled). Same for an ID of an anchor element, it would navigate to its hRef. Other cases are supported as well.

Combined with automatic HTML5 form validation, you really do not need any JavaScript in order to use this functionality in a basic form page, or any page for that matter.

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Si Robertson]

It would be better to follow the W3C, like Mozilla have done.

http://www.w3.org/html/wg/drafts/html/master/interactive-elements.html#context-menus

Personally I don't see a problem with the way custom context menus are defined in HTML. Nothing is preventing them from being generated in JavaScript at runtime and injected into the page, if that's what people want to do.

[PhistucK]

Note that the W3C HTML5 specification and the WHATWG HTML Living Standard are the same in this regard.

☆PhistucK

[Ian Hickson]

On Fri, 11 Apr 2014, Dimitri Glazkov wrote:
>
> If we do, can we please layer it as JS API, rather than an HTML element?
> One can always build a <menu> element on top of that.

I recommend sending such feedback to the WHATWG list (though I must admit
I don't understand why this particular feature would be worth doing as a
JS API rather than declaratively).

[sanjo...@samsung.com]

As I see there are few positive response for context menu, I tried investigating implementation effort and I created a CL for review <https://codereview.chromium.org/243403006/>. But before proceeding with review, can we have consensus (LGTM or not LGTM) on this feature?

[Adam Barth]

My reading of this thread is that I was the most vocal objector.  I've been convinced by this discussion that we should implement this feature.  IMHO, you should go for it.

Adam

[Ojan Vafai]

I think we should move forward with this. It's probably not the API I would design, but given that Mozilla has already shipped this, the benefits of a different design are lower than the benefits of being compatible with their implementation. And I agree that we need this API in order to match the capabilities of native platforms. This doesn't rule out implementing a JS API in the future and layering this declarative API on top of it.

[tobias....@gmail.com]

Seams they are working on it, i found the attribute "contextmenu" in the latest chrome canary.

[PhistucK]

Sort of - you can get updates by starring the issue -

crbug.com/87553

☆PhistucK

[PhistucK]

It does not seem to work yet :( -
http://davidwalsh.name/demo/html5-context-menu.php

☆PhistucK

[Si Robertson]

The IDL files and APIs are available in Blink but it looks like the context menu related bits and pieces require a chrome flag to be enabled (RuntimeEnabled=ContextMenu).

https://github.com/si-robertson/blink-apis/blob/master/apis/HTMLMenuElement.idl

[PhistucK]

It is controlled by the experimental web platform features flag, which I enabled (using the canary, of course).

https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/platform/RuntimeEnabledFeatures.in&sq=package:chromium&q=RuntimeEnabledFeatures&type=cs&l=34

It still does not work. Maybe some day. :)

☆PhistucK

[Eiji Kitamura]

Here's a tiny demo I've written.

http://jsbin.com/guzapu/2/edit?html,css,output

It works fine on canary with web platform features flag on.

Although it's missing `menuitem[icon]` and `menu[type=toolbar]`.

--

Eiji Kitamura | Developer Advocate | google.com/+agektmr | +81-80-1150-6480

[tobias....@gmail.com]

Nice,
but Firefox uses menu[type=context], 

Its not compatible :(

[Si Robertson]

Chrome is correct, "popup" the required type value. Firefox, as usual, is ignoring the specification :)

https://html.spec.whatwg.org/multipage/forms.html#context-menus

[smaug]

On 11/14/2014 02:13 PM, Si Robertson wrote:
> Chrome is correct, "popup" the required type value. Firefox, as usual, is ignoring the specification :)
>

eh.
The spec has just changed for some reason after the feature was implemented in Gecko.
http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Dec/0264.html


-Olli

> https://html.spec.whatwg.org/multipage/forms.html#context-menus
>
>
>
> On 14 November 2014 10:50, <tobias....@gmail.com <mailto:tobias....@gmail.com>> wrote:
>
> Nice,
> but Firefox uses menu[type=context],
> Its not compatible :(
>
> Am Freitag, 14. November 2014 09:41:21 UTC+1 schrieb Eiji Kitamura:
>
> Here's a tiny demo I've written.

> http://jsbin.com/guzapu/2/__edit?html,css,output <http://jsbin.com/guzapu/2/edit?html,css,output>

>
> It works fine on canary with web platform features flag on.
> Although it's missing `menuitem[icon]` and `menu[type=toolbar]`.
>
> On Fri, Nov 14, 2014 at 3:29 AM, PhistucK <phis...@gmail.com> wrote:
>
> It is controlled by the experimental web platform features flag, which I enabled (using the canary, of course).

> https://code.google.com/p/__chromium/codesearch#chromium/__src/third_party/WebKit/Source/__platform/__RuntimeEnabledFeatures.in&sq=__package:chromium&q=__RuntimeEnabledFeatures&type=__cs&l=34

> <https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/platform/RuntimeEnabledFeatures.in&sq=package:chromium&q=RuntimeEnabledFeatures&type=cs&l=34>
>
> It still does not work. Maybe some day. :)
>
>

> ☆*PhistucK*

>
> On Thu, Nov 13, 2014 at 8:21 PM, Si Robertson <retrom...@gmail.com> wrote:
>
> The IDL files and APIs are available in Blink but it looks like the context menu related bits and pieces require a chrome flag to be
> enabled (RuntimeEnabled=ContextMenu).
>

> https://github.com/si-__robertson/blink-apis/blob/__master/apis/HTMLMenuElement.__idl

> <https://github.com/si-robertson/blink-apis/blob/master/apis/HTMLMenuElement.idl>
>
>
> On 13 November 2014 17:27, PhistucK <phis...@gmail.com> wrote:
>
> It does not seem to work yet :( -

> http://davidwalsh.name/demo/__html5-context-menu.php <http://davidwalsh.name/demo/html5-context-menu.php>
>
>
> ☆*PhistucK*

>
> On Thu, Nov 13, 2014 at 7:14 PM, PhistucK <phis...@gmail.com> wrote:
>
> Sort of - you can get updates by starring the issue -

> crbug.com/87553 <http://crbug.com/87553>
>
>
> ☆*PhistucK*

>
> On Thu, Nov 13, 2014 at 6:51 PM, <tobias....@gmail.com> wrote:
>
> Seams they are working on it, i found the attribute "contextmenu" in the latest chrome canary.
>
>
> Am Mittwoch, 30. April 2014 03:57:33 UTC+2 schrieb Ojan Vafai:
>
> I think we should move forward with this. It's probably not the API I would design, but given that Mozilla has already
> shipped this, the benefits of a different design are lower than the benefits of being compatible with their
> implementation. And I agree that we need this API in order to match the capabilities of native platforms. This doesn't
> rule out implementing a JS API in the future and layering this declarative API on top of it.
>
>
> On Mon, Apr 28, 2014 at 11:18 AM, 'Adam Barth <aba...@google.com>' via blink-dev <blin...@chromium.org> wrote:
>
> My reading of this thread is that I was the most vocal objector. I've been convinced by this discussion that we
> should implement this feature. IMHO, you should go for it.
>
> Adam
>
>
> On Mon Apr 28 2014 at 2:19:30 AM, <sanjo...@samsung.com> wrote:
>
> As I see there are few positive response for context menu, I tried investigating implementation effort and I

> created a CL for review <https://codereview.__chr____omium.org/243403006/

> <https://codereview.chromium.org/243403006/>>. But before proceeding with review, can we have consensus (LGTM
> or not LGTM) on this feature?
>
> On Friday, April 11, 2014 11:36:03 PM UTC+5:30, Ian Hickson wrote:
>
> On Fri, 11 Apr 2014, Dimitri Glazkov wrote:
> >
> > If we do, can we please layer it as JS API, rather than an HTML element?
> > One can always build a <menu> element on top of that.
>
> I recommend sending such feedback to the WHATWG list (though I must admit
> I don't understand why this particular feature would be worth doing as a
> JS API rather than declaratively).
>
> --
> Ian Hickson U+1047E )\._.,--....,'``. fL
> http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
> Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
>
>

> To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@__chromium.org.
>
>
>
>
>
>
>
>
> --
> Eiji Kitamura | Developer Advocate |google.com/+agektmr <http://google.com/+agektmr>__ | +81-80-1150-6480

>
>
> To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org

> <mailto:blink-dev+...@chromium.org>.

[Si Robertson]

Just changed? The spec hasn't changed for about two years as far as I can tell, but I could be looking in the wrong places.

[smaug]

On 11/14/2014 03:38 PM, Si Robertson wrote:
> Just changed? The spec hasn't changed for about two years as far as I can tell, but I could be looking in the wrong places.

I didn't mean "just" as a temporal thing, but as a comment to your odd
"Firefox, as usual, is ignoring the specification" comment.
Gecko followed the spec, then the spec changed and Gecko hasn't been updated to follow the newer version of the spec.
http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Dec/0264.html has the comment about the spec change.

>
>
> On Friday, 14 November 2014 13:11:10 UTC, smaug wrote:
>
> On 11/14/2014 02:13 PM, Si Robertson wrote:
> > Chrome is correct, "popup" the required type value. Firefox, as usual, is ignoring the specification :)
> >
>
> eh.
> The spec has just changed for some reason after the feature was implemented in Gecko.
> http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Dec/0264.html
> <http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Dec/0264.html>
>
>
> -Olli
>
>

> > https://html.spec.whatwg.org/multipage/forms.html#context-menus <https://html.spec.whatwg.org/multipage/forms.html#context-menus>

> >
> >
> >
> > On 14 November 2014 10:50, <tobias....@gmail.com <javascript:> <mailto:tobias....@gmail.com <javascript:>>> wrote:
> >
> > Nice,
> > but Firefox uses menu[type=context],
> > Its not compatible :(
> >
> > Am Freitag, 14. November 2014 09:41:21 UTC+1 schrieb Eiji Kitamura:
> >
> > Here's a tiny demo I've written.

> > http://jsbin.com/guzapu/2/__edit?html,css,output <http://jsbin.com/guzapu/2/__edit?html,css,output>
> <http://jsbin.com/guzapu/2/edit?html,css,output <http://jsbin.com/guzapu/2/edit?html,css,output>>

> >
> > It works fine on canary with web platform features flag on.
> > Although it's missing `menuitem[icon]` and `menu[type=toolbar]`.
> >
> > On Fri, Nov 14, 2014 at 3:29 AM, PhistucK <phis...@gmail.com> wrote:
> >
> > It is controlled by the experimental web platform features flag, which I enabled (using the canary, of course).
> >
> https://code.google.com/p/__chromium/codesearch#chromium/__src/third_party/WebKit/Source/__platform/__RuntimeEnabledFeatures.in&sq=__package:chromium&q=__RuntimeEnabledFeatures&type=__cs&l=34
> <https://code.google.com/p/__chromium/codesearch#chromium/__src/third_party/WebKit/Source/__platform/__RuntimeEnabledFeatures.in&sq=__package:chromium&q=__RuntimeEnabledFeatures&type=__cs&l=34>
>
> >
> <https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/platform/RuntimeEnabledFeatures.in&sq=package:chromium&q=RuntimeEnabledFeatures&type=cs&l=34
> <https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/platform/RuntimeEnabledFeatures.in&sq=package:chromium&q=RuntimeEnabledFeatures&type=cs&l=34>>
>
> >
> > It still does not work. Maybe some day. :)
> >
> >
> > ☆*PhistucK*
> >
> > On Thu, Nov 13, 2014 at 8:21 PM, Si Robertson <retrom...@gmail.com> wrote:
> >
> > The IDL files and APIs are available in Blink but it looks like the context menu related bits and pieces require a chrome flag
> to be
> > enabled (RuntimeEnabled=ContextMenu).
> >
> > https://github.com/si-__robertson/blink-apis/blob/__master/apis/HTMLMenuElement.__idl

> <https://github.com/si-__robertson/blink-apis/blob/__master/apis/HTMLMenuElement.__idl>
> > <https://github.com/si-robertson/blink-apis/blob/master/apis/HTMLMenuElement.idl

> <https://github.com/si-robertson/blink-apis/blob/master/apis/HTMLMenuElement.idl>>
> >
> >
> > On 13 November 2014 17:27, PhistucK <phis...@gmail.com> wrote:
> >
> > It does not seem to work yet :( -

> > http://davidwalsh.name/demo/__html5-context-menu.php <http://davidwalsh.name/demo/__html5-context-menu.php>
> <http://davidwalsh.name/demo/html5-context-menu.php <http://davidwalsh.name/demo/html5-context-menu.php>>

> >
> >
> > ☆*PhistucK*
> >
> > On Thu, Nov 13, 2014 at 7:14 PM, PhistucK <phis...@gmail.com> wrote:
> >
> > Sort of - you can get updates by starring the issue -

> > crbug.com/87553 <http://crbug.com/87553> <http://crbug.com/87553>

> >
> >
> > ☆*PhistucK*
> >
> > On Thu, Nov 13, 2014 at 6:51 PM, <tobias....@gmail.com> wrote:
> >
> > Seams they are working on it, i found the attribute "contextmenu" in the latest chrome canary.
> >
> >
> > Am Mittwoch, 30. April 2014 03:57:33 UTC+2 schrieb Ojan Vafai:
> >
> > I think we should move forward with this. It's probably not the API I would design, but given that Mozilla has
> already
> > shipped this, the benefits of a different design are lower than the benefits of being compatible with their
> > implementation. And I agree that we need this API in order to match the capabilities of native platforms. This
> doesn't
> > rule out implementing a JS API in the future and layering this declarative API on top of it.
> >
> >
> > On Mon, Apr 28, 2014 at 11:18 AM, 'Adam Barth <aba...@google.com>' via blink-dev <blin...@chromium.org> wrote:
> >
> > My reading of this thread is that I was the most vocal objector. I've been convinced by this discussion
> that we
> > should implement this feature. IMHO, you should go for it.
> >
> > Adam
> >
> >
> > On Mon Apr 28 2014 at 2:19:30 AM, <sanjo...@samsung.com> wrote:
> >
> > As I see there are few positive response for context menu, I tried investigating implementation effort
> and I
> > created a CL for review <https://codereview.__chr____omium.org/243403006/

> <http://chr____omium.org/243403006/>
> > <https://codereview.chromium.org/243403006/ <https://codereview.chromium.org/243403006/>>>. But before

> proceeding with review, can we have consensus (LGTM
> > or not LGTM) on this feature?
> >
> > On Friday, April 11, 2014 11:36:03 PM UTC+5:30, Ian Hickson wrote:
> >
> > On Fri, 11 Apr 2014, Dimitri Glazkov wrote:
> > >
> > > If we do, can we please layer it as JS API, rather than an HTML element?
> > > One can always build a <menu> element on top of that.
> >
> > I recommend sending such feedback to the WHATWG list (though I must admit
> > I don't understand why this particular feature would be worth doing as a
> > JS API rather than declaratively).
> >
> > --
> > Ian Hickson U+1047E )\._.,--....,'``. fL
> > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
> > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
> >
> >
> > To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@__chromium.org

> <http://chromium.org>.
> >
> >
> >
> >
> >
> >
> >
> >
> > --
> > Eiji Kitamura | Developer Advocate |google.com/+agektmr <http://google.com/+agektmr> <http://google.com/+agektmr>__ | +81-80-1150-6480
> >
> >
> > To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org <javascript:>
> > <mailto:blink-dev+...@chromium.org <javascript:>>.
>
> To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org
> <mailto:blink-dev+...@chromium.org>.

[Yoav Weiss]

On Fri, Nov 14, 2014 at 1:13 PM, Si Robertson <retrom...@gmail.com> wrote:

Chrome is correct, "popup" the required type value. Firefox, as usual, is ignoring the specification :)

 

It's probably best to avoid "as usual" style comments around here (and in general :) ) 

[Si Robertson]

Fair enough, I will rephrase my comment.

Mozilla are taking their sweet time as usual :D

Anyway, that's just personal opinion and I could have kept it out of the conversation, so my bad. The point is the popup value is correct, and strangely enough the MDN Docs also reflect that.

[PhistucK]

MDN is community based, so someone must have simply updated the article.

It does not necessarily reflect the implementation of a Firefox product (it has a whole section about CSS filters while only the SVG based one was, or still is, supported)

And yes, you probably should have kept this opinion to yourself. What you can do is to search for an issue at bugzilla.mozilla.org (or file an issue if you cannot find one) and vote for it in order to make them be (more?) aware of the issue.

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[PhistucK]

Anyway, this is indeed an issue. Unless Firefox changes its implementation to match, I do not support implementing a non interoperable API in Blink. This is a waste of time.

☆PhistucK

[Si Robertson]

Sorry man, that doesn't make any sense. Chrome/Blink shouldn't be held back simply because other browser vendors are having trouble keeping up, no progress would ever be made that way. Whether or not developers choose to use the API is a judgement call, we all understand the risks involved in using new APIs. The menu/menuitem specification has been stable for two years now.

[PhistucK]

I did not check it, but I am can be fairly sure that the old context menu wording was also there for a few years.

Currently, there is a shipping (stale) implementation and pages may depend on it.

Implementing (and shipping) an incompatible implementation would simply create a mess (some pages would use that, some pages would use this, it is 2000 - 2008 again, like with addEventListener/attachEvent and document.layers and document.all). This is definitely not the way to go.

☆PhistucK

[Ian Hickson]

On Fri, 14 Nov 2014, smaug wrote:
>
> Gecko followed the spec, then the spec changed and Gecko hasn't been updated
> to follow the newer version of the spec.

Actually, this is one of the rarer times where the Gecko implementation
was wildly at variance with the spec. The spec later changed in response
to the feedback that resulted from that initial experimental non-standard
implementation. Gecko didn't "follow the spec" in this case, though.
(Which is fine, that's how it should be when an implementor thinks the
spec isn't good.)

[smaug]

On 11/15/2014 01:42 AM, Ian Hickson wrote:
> On Fri, 14 Nov 2014, smaug wrote:
>>
>> Gecko followed the spec, then the spec changed and Gecko hasn't been updated
>> to follow the newer version of the spec.
>
> Actually, this is one of the rarer times where the Gecko implementation
> was wildly at variance with the spec. The spec later changed in response
> to the feedback that resulted from that initial experimental non-standard
> implementation. Gecko didn't "follow the spec" in this case, though.
> (Which is fine, that's how it should be when an implementor thinks the
> spec isn't good.)
>

(Not that this is too useful, but...)
type attribute used to have "context" as one of its values.
We're talking why Gecko supports type="context". Not other parts of the menu handling.

- <p>The <dfn title="attr-menu-type"><code>type</code></dfn> attribute
- is an <span>enumerated attribute</span> indicating the kind of menu
- being declared. The attribute has three states. The <code
- title="attr-menu-type-context">context</code> keyword maps to the
- <dfn title="context menu state">context menu</dfn> state, in which
- the element is declaring a context menu. The <code
- title="attr-menu-type-toolbar">toolbar</code> keyword maps to the
- <dfn title="toolbar state">toolbar</dfn> state, in which the
- element is declaring a toolbar. The attribute may also be
- omitted. The <i>missing value default</i> is the <dfn title="list
- state">list</dfn> state, which indicates that the element is merely
- a list of commands that is neither declaring a context menu nor
- defining a toolbar.</p>


https://html5.org/r/7602

[Si Robertson]

Would it not be possible for Blink to support "popup" and "context" for a while, and treat them as the same value. We're only talking about a couple of enum values here, the element name or behaviour isn't any different.

Seems like a simple solution to me.

The use of "context" could trigger a DevTools warning informing developers the value is deprecated.

[Elliott Sprehn]

The current implementation also breaks Chrome OS where certain apps use a <menuitem> element with slightly different syntax.

https://code.google.com/p/chromium/issues/detail?id=434240

[sanjo...@samsung.com]

| <menuitem>
|   THIS TEXT SHOULD NOT BE VISIBLE
| </menuitem>

This is an invalid markup.  <menuitem> can't have children.

Specification: https://html.spec.whatwg.org/multipage/forms.html#the-menuitem-element

[sanjo...@samsung.com]

Filed an issue for mozilla firefox https://bugzilla.mozilla.org/show_bug.cgi?id=1100749

[PhistucK]

I just tested the canary and saw the implementation (I used the Developer Tools to change "context" to "popup" in the demo). This is cool!

However, I have one concern - is it intentional that only the specified HTML5 menu items are shown (along with "Inspect element") and the rest (the standard context menu items) are gone?

This is inconvenient for the user and might not even be what the developer intended...

☆PhistucK

[sanjo...@samsung.com]

Yes, this is intentional. Filed an issue here http://code.google.com/p/chromium/issues/detail?id=415889

[tobias....@gmail.com]

If i use type="context" it will not work in chrome, 

if i use type="popup" it will not work in firefox.
Its not easy feature detect which type it supports.
My CMS supports the firefox-way for a long time now.
My polyfill for Chrome will not work anymore.... :(

Please support both ways.

[PhistucK]

Instead, Firefox will support both of the ways soon.

https://bugzilla.mozilla.org/show_bug.cgi?id=1100749

(The status is "Assigned")

☆PhistucK

[Simon Pieters]

On Mon, 08 Dec 2014 14:16:51 +0100, <tobias....@gmail.com> wrote:

> If i use type="context" it will not work in chrome,
> if i use type="popup" it will not work in firefox.
> Its not easy feature detect which type it supports.

It should be easy to detect, and looks like it is in Firefox but not in
Chrome/Opera.

https://html.spec.whatwg.org/multipage/forms.html#attr-menu-type
https://html.spec.whatwg.org/multipage/forms.html#dom-menu-type
https://html.spec.whatwg.org/multipage/infrastructure.html#limited-to-only-known-values

function menuPopupSupported() {
var m = document.createElement('menu');
m.type = 'popup';
return m.type === 'popup';
}

I've filed https://code.google.com/p/chromium/issues/detail?id=439974


I suppose I would do it like this to decide which keyword to use, given
the current situation:

function menuPopupKeyword() {
var m = document.createElement('menu');
// default value should be 'toolbar' per spec but in Firefox/old spec
it's 'list'
if (m.type === 'list') {
m.type = 'context;
if (m.type === 'context') {
return 'context';
}
}
return 'popup';

}

> My CMS supports the firefox-way for a long time now.
> My polyfill for Chrome will not work anymore.... :(
> Please support both ways.

I'd rather we did not support both keywords. In my opinion, if there is
too much Web context expecting 'context' to work, we should change the
spec to use that keyword. Otherwise, we should only support 'popup'. As
far as I know, we don't have any data yet.

--
Simon Pieters
Opera Software

[Elliott Sprehn]

On Mon, Dec 8, 2014 at 10:38 AM, Simon Pieters <sim...@opera.com> wrote:

On Mon, 08 Dec 2014 14:16:51 +0100, <tobias....@gmail.com> wrote:

...

I'd rather we did not support both keywords. In my opinion, if there is too much Web context expecting 'context' to work, we should change the spec to use that keyword. Otherwise, we should only support 'popup'. As far as I know, we don't have any data yet.

Why was it decided to call this thing popup anyway? I've never heard anyone ever refer to these kinds of menus as popups, it seems like it's confusing and we should just match Firefox in Chrome.

- E 

[Simon Pieters]

On Mon, 08 Dec 2014 18:08:00 +0100, Elliott Sprehn <esp...@chromium.org>
wrote:

- <menu type=popup> is implemented as <menu type=context> in Gecko.
This is an unfortunate incompatibility. I renamed "context" to "popup"
because it doesn't make sense to have <button type=menu menu="">
pointing at a <menu type=context> since then it's not a context menu
but a drop-down menu. Since both context menus and drop-down menus are
also called "pop-up menus" I went with "popup". If there's too much
content depending on type=context let me know and I'll change it back.
]]
http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Dec/0264.html

[Si Robertson]

There shouldn't be any live commercial content relying on this feature yet because, according to caniuse.com, Firefox is the only browser that actually exposes it. A few personal sites may be using it but I think it's safe to class those as edge cases.

http://caniuse.com/#feat=menu

I would stick with the currently spec'd name, i.e. "popup".

[Elliott Sprehn]

On Mon, Dec 8, 2014 at 12:47 PM, Si Robertson <retrom...@gmail.com> wrote:

There shouldn't be any live commercial content relying on this feature yet because, according to caniuse.com, Firefox is the only browser that actually exposes it. A few personal sites may be using it but I think it's safe to class those as edge cases.

http://caniuse.com/#feat=menu

I would stick with the currently spec'd name, i.e. "popup".

Just because it's Firefox only doesn't mean it can't be used on popular websites or large business applications. 

I see now that all of this naming complexity comes from trying to overload <menu> to do three different things:

1. Show a context menu (right click or long press).

2. Show a popup menu (anchored menu)

3. Display toolbars.

That seems unfortunate overloading, but I guess I can see why you'd want a generic name.

My suggestion would be to use type=popup in blink, but add a UseCounter for type=context to see if there's a bunch of Firefox only content that now fails to work in Chrome. If that proves to be true we might want to make the spec allow either.

[Elliott Sprehn]

On Mon, Dec 8, 2014 at 12:47 PM, Si Robertson <retrom...@gmail.com> wrote:

There shouldn't be any live commercial content relying on this feature yet because, according to caniuse.com, Firefox is the only browser that actually exposes it. A few personal sites may be using it but I think it's safe to class those as edge cases.

http://caniuse.com/#feat=menu

I would stick with the currently spec'd name, i.e. "popup".

Just because it's Firefox only doesn't mean it can't be used on popular websites or large business applications. 

I see now that all of this naming complexity comes from trying to overload <menu> to do three different things:

1. Show a context menu (right click or long press).

2. Show a popup menu (anchored menu)

3. Display toolbars.

That seems unfortunate overloading, but I guess I can see why you'd want a generic name.

My suggestion would be to use type=popup in blink, but add a UseCounter for type=context to see if there's a bunch of Firefox only content that now fails to work in Chrome. If that proves to be true we might want to make the spec allow either.

[Simon Pieters]

On Mon, 08 Dec 2014 16:38:55 +0100, Simon Pieters <sim...@opera.com> wrote:

> As far as I know, we don't have any data yet.

I looked into this a bit using httparchive[1].

SELECT COUNT(*) as num,
CASE
WHEN REGEXP_MATCH(LOWER(body),
r'<menu\s([^>]+\s)?type\s*=\s*["\']?context') THEN "context"
WHEN REGEXP_MATCH(LOWER(body),
r'<menu\s([^>]+\s)?type\s*=\s*["\']?popup') THEN "popup"
WHEN REGEXP_MATCH(LOWER(body),
r'<menu\s([^>]+\s)?type\s*=\s*["\']?toolbar') THEN "toolbar"
ELSE "other"
END as stat
FROM [httparchive:runs.2014_08_15_requests_body]
WHERE mimeType CONTAINS "html"
AND REGEXP_MATCH(LOWER(body), r'<menu\s([^>]+\s)?type\s*=')
GROUP BY stat
ORDER BY num desc


Query Results

Row num stat
1 10070 context
2 76 toolbar
3 24 other

When looking for <menu> without a type attribute, the result is 992.

So there is a non-trivial amount of <menu type=context> in this dataset,
and zero <menu type=popup>.

I will do some more research around a related issue with <menuitem> and
then send my findings and a proposal to whatwg.

[1]
http://bigqueri.es/t/analyzing-html-css-and-javascript-response-bodies/442

[Domenic Denicola]

Hi Sanjoy and blink-dev,

We're trying to determine the future of the menu and command features in the HTML spec. Would you mind weighing in on https://github.com/whatwg/html/issues/237? For example, we are wondering if the currently-specified "command API" has any value, or if <menu type="toolbar"> should be kept. It sounds like we are very close to two interoperable implementations of <menu type="popup"> and its associated <menuitem>, but for the rest we are not so sure.

On Tuesday, February 4, 2014 at 7:18:57 AM UTC-5, sanjo...@samsung.com wrote:

Primary eng (and PM) emails

sanjo...@samsung.com

Spec

http://www.whatwg.org/specs/web-apps/current-work/#context-menus

http://www.whatwg.org/specs/web-apps/current-work/#the-menu-element

Summary

Implement contextmenu attribute which gives a mechanism to specify custom context menu for a particular element. The value of the contextmenu attribute must be the ID of menu element with type popup.

Motivation

- Allow web developers to define custom context menu for an element.

- Context menus are handy on touch based devices where DnD conflicts with scrolling.

- This will give web apps a whole new dimension.

-  Firefox implements this. http://people.mozilla.org/~prouget/bugs/context-menu-test/test.html looks good on mobile FF. 

Compatibility Risk

Mozilla is currently shipping this.

Demo at 

http://people.mozilla.org/~prouget/bugs/context-menu-test/test.html

Ongoing technical constraints

None.

Will this feature be supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS and Android)?

Yes.

OWP launch tracking bug?

http://code.google.com/p/chromium/issues/detail?id=87553

https://bugs.webkit.org/show_bug.cgi?id=58454

Row on feature dashboard?

No

Requesting approval to ship?

No

[PhistucK]

type="context" changed back to type="popup" -

https://github.com/whatwg/html/pull/241

What is the status of this feature? Can you change it to support "popup" instead?

What is keeping you from posting an intent to ship?

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Elliott Sprehn]

On Tue, Nov 24, 2015 at 5:50 AM, PhistucK <phis...@gmail.com> wrote:

type="context" changed back to type="popup" -

https://github.com/whatwg/html/pull/241

What is the status of this feature? Can you change it to support "popup" instead?

What is keeping you from posting an intent to ship?

Turning this on used to break apple websites that used the elements in a way that wasn't compatible with the html parser changes the spec wants. I don't think we had luck getting apple to update the website, but maybe it's changed since then. :)

- E

[Simon Pieters]

On Tue, 24 Nov 2015 14:50:56 +0100, PhistucK <phis...@gmail.com> wrote:

> type="context" changed back to type="popup" -
> https://github.com/whatwg/html/pull/241
>
> What is the status of this feature? Can you change it to support "popup"
> instead?

The spec change cited above was the other way around, FWIW. :-)

[PhistucK]

Oops. :) Then it should be changed in the experimental implementation as well. Perhaps that will also resolve the Apple issue (not issue number, so I am not sure what is the issue).

☆PhistucK

[TAMURA, Kent]

Hmm, Sanjoy didn't respond in this thread.

AFAIK, possible blockers are:

 - crbug.com/412945 : Broken site with the correct <menuitem> parsing

 - |icon| attribute is not implemented.

   I guess it needs to add some complex code.

--

TAMURA Kent
Software Engineer, Google

[Anne van Kesteren]

On Thu, Jan 14, 2016 at 8:11 AM, TAMURA, Kent <tk...@chromium.org> wrote:
> AFAIK, possible blockers are:
> - crbug.com/412945 : Broken site with the correct <menuitem> parsing

Note that we're still looking for feedback from Chrome in
https://github.com/whatwg/html/issues/234. (And it seems from Firefox
as well, though we don't implement it as void at the moment.)


--
https://annevankesteren.nl/

[TAMURA, Kent]

On Thu, Jan 14, 2016 at 4:11 PM, TAMURA, Kent <tk...@chromium.org> wrote:

Hmm, Sanjoy didn't respond in this thread.

Sanjoy is not responsible for implementation bugs and related HTML specification discussion.

If no one wants to own the feature, I'll remove the implementation.

[sanjoy pal]

 - crbug.com/412945 : Broken site with the correct <menuitem> parsing

> I have logged a bug in https://bugreport.apple.com but no action was taken.

 - |icon| attribute is not implemented.

   I guess it needs to add some complex code.

> I tried implementing chromium side code here but could not write a test

https://codereview.chromium.org/892953002/

I shall a put a patch to "Change <menuitem> from void to like-<option>"

https://github.com/whatwg/html/commit/99a93cf8c65602d3b7ef541b12c0252d79d515f2

[Simon Pieters]

On Mon, 28 Mar 2016 09:41:25 +0200, sanjoy pal <sanjo...@gmail.com>
wrote:

> - crbug.com/412945 : Broken site with the correct <menuitem> parsing
>> I have logged a bug in https://bugreport.apple.com but no action was
> taken.

> [...]

> I shall a put a patch to "Change <menuitem> from void to like-<option>
> <https://github.com/whatwg/html/commit/99a93cf8c65602d3b7ef541b12c0252d79d515f2>
> "

> https://github.com/whatwg/html/commit/99a93cf8c65602d3b7ef541b12c0252d79d515f2

Any progress on this? As I noted in
https://github.com/whatwg/html/pull/907#issuecomment-204375907 the
proposed spec change doesn't actually fix the page in question (because it
uses <menu><menuitem><menu> and <menu> implies </menuitem>). Should we
power through the Apple documentation page by shipping anyway (together
with Mozilla?)?

[PhistucK]

I really think we should. It makes no sense to change the specification just because a single website does that. Especially one that is maintained.

☆PhistucK