Menu item selection should not be stored

[Ortham]

This is a regression from the behaviour of paper-menu in Polymer 0.5 - clicking on a menu item should fire a relevant event (iron-select is fine), but the menu should not remember which item was last selected, because that's completely unintuitive behaviour and flies in the face established menu behaviour.

With the current behaviour, if I have an app menu and I select an item in that menu, the next time I open the menu, that item is still highlighted, and selecting it again has no effect. For a common example where this is clearly broken, consider an overflow menu with a Save As item.

As it is, this is a block for me updating my app to Polymer 1.x, and I'm sure I'm not alone (though it can be hacked around, that shouldn't really be necessary...).

[phidias51]

Had a similar discussion on Slack about this. Apparently when they designed it, they meant for it to be used for navigation, not as a real menu. But I agree with you, it definitely needs to be fixed.

[bicknellr]

There's not a great answer right now, but I definitely agree when you all say this component should act more like a 'menu' in the toolbar / context-menu sense. Like @phidias51 mentioned, I think paper-menu was originally designed to be similar to the select element with sort of a tacked-on collapsible tree thing, then paper-listbox took over the select-like case and left paper-menu trying to balance backwards compatibility and the expectations of users (with a non-select-primed understanding of the word of 'menu') who are running across the element for the first time. There's a few things playing into this that need to be worked out, like how to merge overlays' need to be positioned outside of their (possibly overflow: hidden) container's bounding box while not throwing away the accessibility benefits of a reasonably structured DOM. Particularly, if we can maintain that the document tree mirrors the conceptual hierarchy of the app, document-order focus traversal continues to apply, which is good for users that want / need to navigate linearly (without a mouse). (@valdrinkoshi has been looking into this a lot lately.)

Admittedly, this response is kind of a dodge, but the problem is on our minds too.

[phidias51]

@bicknellr As you alluded earlier, I think part of the problem is just setting expectations based on the name. If it's meant to be used as a fancy form of the select element, or as a navigation-related element, then the name should reflect that (i.e. "paper-select-menu", or "paper-nav-menu". If it's meant to be used as a menu, then it should act like a menu in Google Docs (i.e. "paper-app-menu").

[indolering]

The workaround for this is to enable multi-selection and then deselect that selection (this.$.select_menu.select(index)) in your on-tap function.