New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 16 users

Issue metadata

Status: Fixed
Closed: Apr 2017
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

issue 87553

Sign in to add a comment

Issue 412945: <menuitem> parsing is no web-compatible

Reported by, Sep 10 2014 Project Member

Issue description

If you open the below link in M39 (39.0.2145.4 (Official Build)) everything appears to sit on top of itself. The page renders correctly in M37. I don't have M38 to test with locally.

The scrolling is also very busted.
Screenshot from 2014-09-10 17:01:50.png
192 KB View Download

Comment 1 by, Sep 10 2014

This does not reproduce on M39 mac Retina. It does reproduce on Linux and Mac non-retina.

Comment 2 by, Sep 10 2014

The website has the following:

<meta name="viewport" content="width=device-width, maximum-scale=1.0">

I wonder if that's not the trigger. +Antonio as he knows this code well.

Comment 3 by, Sep 11 2014

Labels: Needs-Feedback
dsinclair@,I working on Windows7/Linux(Ubuntu 12.04)/MAC (OSX 10.9.4)-MACBook Air and i am unable to reproduce the above issue as per screen shot with reported version men ,M38 (38.0.2125.58 (Official Build 291101) beta and with Latest canary :39.0.2152.0(M39).

When comes to Scrolling i could find issue with MAC  when "On this Page" drop down is clicked and by clicking down arrow till last item and further  then we can find scroll bar appears and disappears but it doesn't stay there , its working fine with windows and linux.

More over the link  which leads to the page i randomly moved to all the links inside the page but i could not find any such rendering issues or issue shown is screen shot , when i observed screen shot it hows the text "filter list of symbols" in search box given but when  went with the link i could find the text "Search IOS developer Library" ,i tried navigating to different links but i could not find the searchbox with text which is shown in the screen shot ,so i have a doubt that weather i am in right page or not,Please let me know if i am missing any step.

Comment 4 by, Sep 11 2014

Labels: -Needs-Feedback
So, apparently you need to enable 'Experimental Web Platform Features' in about://flags and then everything blows up and you see the above rendering.

Comment 5 by, Sep 12 2014

Labels: -Type-Bug -Needs-Bisect Type-Bug-Regression
Status: Assigned
Able to reproduce the issue in 39.0.2155.0 canary and  38.0.2125.54 beta. Issue not seen in M37 stable.

Broken in M38 beta. 
38.0.2121.3 - Good build
38.0.2122.2 - Bad build

Narrow bisect CL is:

Narrow blink bisect CL is:

Suspecting 180052, 180040. mkwst@, would you please take a look at this issue. Please assign it to concerned Dev if this is not your change.

Comment 6 by, Sep 12 2014

Owner: ----
This is almost certainly not 180040. That CL adds an (as-yet unused) platform interface to Blink. There are a number of CSS-related patches in the range you've specified. I'd take a closer look at those, as they're more likely to have something to do with rendering behavior.

Comment 7 by, Sep 12 2014

I think the CSS properties are not related. The page uses <menuitem> and we have a change in the range ->

Comment 8 by, Sep 15 2014

Yes, this is broken because of this change
But as per the specification here
<menuitem> should not have any end tag, its a self closing tag.
The page packs some html elements in between <menuitem></menuitem>, which are ignored. So, its a problem with the page source.

Comment 9 by, Sep 15 2014

Labels: Cr-Blink-HTML Cr-Blink-HTML-Menu
Status: WontFix
Yeah, this is a web-site bug.

Comment 10 by, Nov 5 2014

 Issue 429538  has been merged into this issue.

Comment 11 by, Nov 18 2014

 Issue 434240  has been merged into this issue.

Comment 12 by, Nov 18 2014

Why doesn't firefox have the same issue we're seeing here?

Comment 14 by, Nov 18 2014

Given that chrome apps, apple websites and firefox all agree we should just
change the spec to match firefox instead of fighting this up hill.

Comment 15 by, Nov 18 2014

I agree with esprehn, we should revert this change and change the spec instead.

Comment 16 by, Nov 19 2014

Internally I found more folks who weren't able to use menuitem correctly (go/csmenuitem, sorry but this is only available to Google employees). Is this really worth following the spec so strictly here? What's the cost of allowing non-self-closing tags vs the benefit of not breaking these existing uses?

Comment 17 by, Nov 19 2014

Labels: -Cr-Blink-Rendering
I'm not sure if there are many broken sites.  We should collect data.  e.g. UseCounter for <menuitem> and <menuitem> with child nodes.

Comment 18 by, Nov 21 2014

Status: Untriaged
I did a search and found a few more sites but no major ones, other than Apple. I also found that menuitem is not particularly popular, other than Apple. Following the spec seems less important than preventing our users from reading the apple documentation., what is the downside to not following the spec here? I think is important enough that we should find a way to contact apple, or revert this change.

Comment 19 by, Nov 21 2014

I think there will not be any issue if we deviate from spec here as we are using "label" of <menuitem> to populate the context menu and ignoring anything between <menuitem></menuitem>. If there is consensus about deviating from spec, I can upload a patch for review.

Comment 20 by, Nov 24 2014

@tkent, @dsinclair, @jchaffraix, how do you all feel about the suggestion in #19?

Comment 21 by, Nov 24 2014

Making our implementation match the other browsers makes sense to me. We should kick off an email to the spec list to see about getting the spec updated to match the implementations.

Comment 22 by, Nov 25 2014

Definitely we should discuss this issue in a standard body.
I don't think we need to change Blink behavior immediately.  This behavior is behind the flag, and doesn't affect a lot of sites.

Comment 23 by, Nov 25 2014

I apologize... I always have the experimental web platform features flag enabled and thought this was affecting all users. My comments above were dire sounding because I thought we were shipping this.

I agree with tkent, please bring this up in a standards body. No need to revert this patch.

Comment 25 by, Aug 25 2015

Blocking: chromium:87553

Comment 26 by, Aug 25 2015

Labels: Needs-Evangelism
Status: ExternalDependency

Comment 27 by, Oct 2 2015

Labels: Hotlist-Recharge
This issue likely requires triage.  The current issue owner may be inactive (i.e. hasn't fixed an issue in the last 30 days or commented in this particular issue in the last 90 days).  Thanks for helping out!


Comment 28 by, Oct 5 2015

Labels: Cr-Blink-Layout
The site still shows up as broken for me. Looks like the spec discussion didn't arrive at any conclusion.

eae@ is this something layout team would be responsible for?

Comment 29 by, Oct 5 2015

Tab, any chance we could get this clarified form a spec perspective?

Comment 30 by, Oct 6 2015

I just pinged the thread again.  I'm like 80% sure this page is just *coincidentally* using elements named <menu>/<menuitem>, and they *mean* them to be unknown elements.  The markup is just stupidly nonsensical otherwise.

If so, this is just an evangelism bug.

Comment 31 by, Oct 7 2015

Ah, that makes sense and matches my analysis of the page. Thanks Tab!

Comment 32 by, Oct 7 2015


There is a proposal to make this work, but it is a bit more complicated and prior research suggests that this is not a common problem, so hopefully evang will be enough. Please comment in the issue if you find more broken pages or evang fails etc.

Comment 33 by, Dec 3 2015

 Issue 550519  has been merged into this issue.

Comment 34 by, Dec 3 2015

Labels: -M-39 -Cr-Blink-Layout Cr-Blink-HTML-Parser

Comment 35 by, Jan 7 2016

Labels: -Type-Bug-Regression -Hotlist-Recharge Type-Bug
Owner: ----

Comment 36 by, Jan 14 2016

Project Member
The following revision refers to this bug:

commit 960e27eea0a509153ee247d7edda7d1c4d49eb53
Author: tkent <>
Date: Thu Jan 14 06:48:01 2016

Add counters for <menuitem>.

- UseCounter::MenuItemElement
  Counts menuitem element usage.
  if chrome://flags/#enable-experimental-web-platform-features is enabled,
  HTMLMenuItemElement is used.  Otherwise, HTMLUnknownElement is used.

- UseCounter::MenuItemCloseTag
  Counts </menuitem>.  <menuitem> is a void element according to the current
  specification.  This counts wrong usages like .

BUG= 412945 

Review URL:

Cr-Commit-Position: refs/heads/master@{#369354}


Comment 37 by, Mar 30 2016

Spec change PR:

html5lib-tests PR:

These PRs are currently awaiting review. If someone here has knowledge and time to take a look, that would be much appreciated.

(Will import the tests to web-platform-tests when they land in html5lib-tests.)

Comment 38 by, Apr 7 2016

 Issue 601631  has been merged into this issue.

Comment 39 by, Apr 7 2016

Summary: Apple API reference page rendering is very broken with 'Experimental Web Platform Features' (was: HealthKit API rendering is very broken)

Comment 40 by, May 2 2016

Labels: -Needs-Evangelism Hotlist-Interop
Status: Available (was: ExternalDependency)
The spec has been changed to mark menuitem as options-like instead of a void element:

Can we please get chromium's implementation fixed so that the Apple docs aren't all messed up when experimental web platform features is enabled (or, worse case, move the <menuitem> support out of experimental)?

Comment 42 by, May 6 2016

Components: -Blink>HTML
Owner: ----

Comment 43 by, May 31 2016

BTW,  I bumped into apple site breakage today (see attachment),
on Canary (53.0.2751.0 (Official Build) canary (64 bit)) with
"experimental-web-platform-features" on.

The search results are all blurry, though you can click on it or select the snippets.
Screenshot 2016-05-31 14.30.44.png
489 KB View Download

Comment 44 by, May 31 2016

#43 -
That is a totally different issue. It is related to position: sticky, or to backdrop-filter. Can you file a new issue?

Comment 45 by, May 31 2016

Oh sure, filed  issue 615957 

Comment 46 by, Jun 8 2016

Status: Started (was: Available)
Given that (after this bug has been open for 2 years) we don't have a concrete plan for preventing this breakage, and chromium developers REALLY need to be able to use the apple developer website, I intend to downgrade the ContextMenu RuntimeEnabledFeature from status=experimental to status=test.

When either the Apple site is fixed, or the implementation is changed to not break, we can re-promote it to experimental.

Comment 47 by, Jun 8 2016

Sorry instead of "chromium developers", what I really meant was ALL people that tend to run with --enable-experimental-web-platform-features (which is a much larger set).  We can't have any experimental feature cause long-lasting breakage on major sites.

Comment 48 by, Jun 9 2016

Project Member
The following revision refers to this bug:

commit 990b0dfe5c98990f3a27e44a2a5e512f5ed3140d
Author: rbyers <>
Date: Thu Jun 09 03:31:03 2016

Remove HTML5 menu tag feature from experimental set

There are website compat issues with this feature on sites that use their
own <menuitem> tags (especially  Remove it from
the "experimental" set until there's a concrete plan in place to either
ship or resolve the issue to prevent ongoing issues for users running
with this flag enabled.

Note that you can always run chromium with
--enable-blink-features=ContextMenu in order to get this feature.

BUG= 412945 

Cr-Commit-Position: refs/heads/master@{#398771}


Comment 49 by, Jun 9 2016

Status: Fixed (was: Started)

Comment 50 by, Jun 9 2016

Status: Available (was: Fixed)
I'm moving this back to available, it is blocking the Menu item launch and, since the underlying issue isn't fixed, we should keep it open to make sure we don't loose track next time we try to enable Menu.

Comment 51 by, Jun 26 2016

Has Apple said anything about fixing their site?

Comment 52 by, Jun 26 2016

Has anyone filed a bug report ("radar"?) with Apple (not WebKit, as it is unrelated)?

Comment 53 by, Jun 27 2016

sanjoy.pal@ said in

> I filed a bug in apple bug tracker but no action is taken.

I've asked hober (Apple) to follow up with the Apple docs people, he said he would do so last week.

Comment 54 by, Jun 30 2016

Owner: ----
Summary: Apple API reference page rendering is very broken with "ContextMenu" feature enabled (was: Apple API reference page rendering is very broken with 'Experimental Web Platform Features')

Comment 55 by, Sep 16 2016

The affected URL no longer uses `menuitem`.

Comment 56 by, Nov 13 2016

Given that the Apple API page no longer (mis)uses `menuitem`, can we re-add ContextMenu to the experimental feature set?

Comment 57 by, Nov 13 2016

If there's someone interested in driving it to ship, then re-adding it is fine with me.  But if we don't have any concrete plans to ship it, then I don't think it's worthwhile to call it "experimental".

Comment 58 by, Nov 28 2016

FYI it appears Mozilla are implementing the parser spec changes now,

Comment 59 by, Nov 29 2016

Firefox is fine with:

    <menuitem id="cmd-copy" label="Copy">Copy</menuitem>

but it only uses the label attribute. It'd be nice to keep the node value for semi-polyfilling the element. Firefox is the only one that understands <menuitem> and it doesn't care about the node value. That's perfect, because Chrome doesn't understand <menuitem label>, but it does understand CSS.

I've been hoping for this feature for 5 years now =) So very very useful for mobile context menus.

Comment 60 by, Feb 3 2017

Status: ExternalDependency (was: Available)
It seems Mozilla is asking to change the parsing rule.

Comment 62 by, Mar 23 2017

Status: Available (was: ExternalDependency)
Summary: <menuitem> parsing (was: Apple API reference page rendering is very broken with "ContextMenu" feature enabled)

Comment 63 by, Mar 23 2017

Summary: <menuitem> parsing is no web-compatible (was: <menuitem> parsing)

Comment 64 by, Apr 13 2017

Status: Assigned (was: Available)

Comment 65 by, Apr 17 2017

Project Member
The following revision refers to this bug:

commit 90d6ed690cab69c72e9a8994ed209f7b3432e44c
Author: yuzus <>
Date: Mon Apr 17 08:49:57 2017

Change <menuitem> parsing rules to match spec

This CL changes <menuitem> parsing rules so that they match the current spec.
<menuitem> is no more a self closing tag.

The link below shows the latest change made to the spec.

BUG= 412945 

Cr-Commit-Position: refs/heads/master@{#464906}


Comment 66 by, Apr 17 2017

Status: Fixed (was: Assigned)

Sign in to add a comment