Status

()

defect
P5
normal
6 years ago
5 months ago

People

(Reporter: Ms2ger, Unassigned)

Tracking

(Depends on 3 bugs, Blocks 2 bugs, {dev-doc-needed})

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

6 years ago
<Hixie> anyone know if gecko has any plans to update its <menu> implementation to match the spec? (the spec was changed at some point to more closely match firefox, but there were some things that didn't quite match firefox for sanity reasons)

Comment 1

6 years ago
I'd like to update it to match the spec, but it's not a priority at the moment. Maybe in Q4.

Comment 2

6 years ago
Bug 617528 should be added as a dependancy to keep the overview. 

Spec is here: http://www.whatwg.org/specs/web-apps/current-work/multipage/interactive-elements.html#menus (and following sections). 

Hixie wrote an overview over the differences between the spec changes and the Firefox implementation[1] (as of Dec 2012): 

>  - Gecko doesn't support <hr>.
Bug 870388. 

>  - Gecko's parser doesn't treat <menuitem> as a void element.
>  […]
>  - Gecko uses the first text node of the <menuitem> element as a label if 
>    there's no label="" attribute.
>    I don't see much point supporting this, especially if we make it void.
Both part of Bug 676236!? (Bug has a checked in patch but is still open.)



The following items have no bug filed: 

>  - <menu type=popup> is implemented as <menu type=context> in Gecko.
I don't know if this is straight renaming or also a slight rewriting.

>  - <menuitem command=""> is not supported in Gecko.

>  - Gecko doesn't support contextmenu="" pointing at a <menu> child of a 
>    <menu type=context> (popup, in spec).

>  - Gecko doesn't drop submenus with no label (it does drop items with no 
>    label, at least in most cases, and seems to strip separators as the 
>    spec suggests).

>  - Gecko doesn't support <button type=menu menu="">.



There's also a mention of how default/"native" context menu items should be displayed (or not) in the spec. There was some discussion on the mailing list and W3C-Bug-12999[2] which is of yet unresolved. See also Bug 705292. 



[1] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-December/038472.html
[2] https://www.w3.org/Bugs/Public/show_bug.cgi?id=12999

Updated

6 years ago
Depends on: 617528

Updated

6 years ago
Blocks: html5test
(Reporter)

Comment 3

6 years ago
Hey Jan, Q4 is here! Got time now? :)
Flags: needinfo?(Jan.Varga)

Comment 4

6 years ago
(In reply to :Ms2ger from comment #3)
> Hey Jan, Q4 is here! Got time now? :)

I doubt I will have time in Q4, maybe next quarter.
Flags: needinfo?(Jan.Varga)

Updated

5 years ago
Blocks: 746087

Updated

5 years ago
Depends on: 676236

Updated

5 years ago
See Also: → 705292

Updated

5 years ago
Depends on: 870388

Comment 5

5 years ago
Any updates on this?
Depends on: 1100749

Comment 6

4 years ago
Adding to comment 2:

"The missing value default is the popup menu state if the parent element is a menu element whose type attribute is in the popup menu state; otherwise, it is the toolbar state."
https://html.spec.whatwg.org/multipage/forms.html#dom-menu-type

document.createElement('menu').type returns 'list', should be 'toolbar' per spec.

<menu type=popup><menu>.type should be 'popup' per spec. (Also <menu type=popup><menu><menu>.type)
Blocks: 1140838
Comment hidden (typo)
The last call spec above documents type context, toolbar, list -- but not popup.
(Reporter)

Comment 9

4 years ago
The link you provided is not relevant to anything; the spec is at <https://html.spec.whatwg.org/multipage/>.
(In reply to :Ms2ger from comment #9)
> The link you provided is not relevant to anything; the spec is at
> <https://html.spec.whatwg.org/multipage/>.

Thanks for the clarification. I must have googled myself into a hole with that now irrelevant reference.

Looks like menu is not part of http://www.w3.org/TR/html5/ but only http://www.w3.org/TR/html51/ right?

My testing of a contextmenu in a web app I work on shows in both Nightly Firefox on Windows and Nightly Firefox OS that type="popup" is always displaying. I have to use type="context" instead.

And this is exactly what this bug is again, right?

So the documentation in
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/menu
is not only hard to understand, it is also currently wrong.

I guess I should update it to document type="context" now (and resolve bug 1140838) and change it again once this bug 897102 is fixed, right?

Comment 11

4 years ago
The MDN documentation is correct, and matches the WHATWG HTML5 spec (which supercedes the W3C HTML5 spec): https://html.spec.whatwg.org/multipage/forms.html#the-menu-element

As per the spec, valid types are "popup" and "toolbar".
Firefox currently implements types "context" and "list", which are not part of the WHATWG HTML5 spec.

Chromium has started to support type="popup" behind a flag.
(In reply to dvpdiner2 from comment #11)
> The MDN documentation is correct, and matches the WHATWG HTML5 spec (which

I should have phrased this differently.

While MDN documentation conforms to the spec, following it will not work in current nightly Firefox on Windows or Firefox OS.

Meanwhile I have added a note to
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/Menu#Summary
stating...

Note: This documentation describes current Firefox implementation. Type 'list' is likely to change to 'toolbar' and 'context' to 'popup' according to HTML5.1 working draft.

and documented current implementation.

> supercedes the W3C HTML5 spec):
> https://html.spec.whatwg.org/multipage/forms.html#the-menu-element
> 
> As per the spec, valid types are "popup" and "toolbar".
> Firefox currently implements types "context" and "list", which are not part
> of the WHATWG HTML5 spec.
> 
> Chromium has started to support type="popup" behind a flag.
(In reply to adrian.aichner from comment #7)

Typo fix:

I guess bug 1140838 can not quickly be fixed considering https://bugzilla.mozilla.org/showdependencygraph.cgi?id=1140838.

Meanwhile I have updated MDN to current implementation and will update again once bug 1100749 is fixed.

Updated

a year ago
Depends on: 1372276

Updated

a year ago
Depends on: 1241353

Updated

10 months ago
Priority: -- → P5

Updated

8 months ago
No longer blocks: 746087
Depends on: 746087

Updated

8 months ago
Blocks: html
You need to log in before you can comment on or make changes to this bug.