__Package version(s)__: "@blueprintjs/core": "3.2.0",
__Browser and OS versions__: Google Chrome 68 / Mac
My code
<Menu>
<MenuItem icon="document-open" text="Open">
{items.map((i, index) => {
return (
<MenuItem
key={index}
text={i.name}
onClick={() => console.log('selected', i.name)}
/>
)
})}
</MenuItem>
...
</Menu>

Emit onClick and close submenu.
Sometimes it does not emit onClick and can not close menu popup.
I doubt lazy behavior to initialize handler, but submenu(MenuItem) does not have lazy prop. I can not find what happen yet.
this is due to #2758, which I disabled in #2776. hasn't shipped yet so set captureDismiss={false} on <Popover> for now.
I tried @blueprintjs/[email protected] but it does not fix this in my env
@mizchi i don't have enough information to offer more guidance. your code looks fine and this works happily on the docs site.
I have the same issue on Firefox 61.0.2 on MacOS 10.13.6 with blueprintjs 3.1.0 and react 16.4.2.
And it also breaks with the same browser/OS on this page https://blueprintjs.com/docs/#core/components/menu
I wanted to highlight I am experiencing this, too, right now.
I have a set of options that, when clicked, fire their onClick method when in the first menu from the popover. When I move them over into a submenu, they only register the click and fire the onClick method about ~1/3 of the time.
Screen capture of this happening:

The component:
<Popover
position={Position.RIGHT}
boundary="viewport"
captureDismiss={false}
content={
<Menu>
<MenuItem text={t`Extrusion Style`}>
<MenuItem
onClick={doSomething(NoExtrusion)}
text={t`No extrusion`} />
<MenuItem
onClick={doSomething(Binned)}
text={t`Binned extrusion`} />
<MenuItem
onClick={doSomething(Continuous)}
text={t`Continuous extrusion`} />
</MenuItem>
</Menu>
}>
<Clickable>
<Box fit>
<Box>
<i className="mdi mdi-cube mdi-18px" />
</Box>
<Box>
<div>
{t`Some text goes here`}
</div>
</Box>
</Box>
</Clickable>
</Popover>
Update: I was able to resolve above issue based off of suggestion in this other issue: https://github.com/palantir/blueprint/issues/3010#issuecomment-443031120
closing in favor of #3010