The MenuItemButton widgets take the input focus when hovered, so when a user clicks on a "Copy" menu item, the thing they were trying to copy no longer has focus until the menu is dismissed, when the menu system puts the focus back where it found it.

It's possible to work around this with delays and/or tracking the context of the widget that had focus, but practically it's nearly impossible to implement cut, copy, and paste because of this.

Some options for fixing the issue include:

1. Implement a "stack" for primaryFocus, where opening a menu item pushes the stack, and selecting a menu item pops the stack before executing the action.
2. Rework menus so that the menu items don't use focus to keep track of what is currently highlighted.

Option 2 seems like the least invasive, but it may eliminate some use cases: people wouldn't be able to use just any widget for menu items, since instead of using focus to indicate that they are currently selected, there would have to be another mechanism that they would interface with, making it harder to use "regular" widgets to represent menu items. In a practical sense, the common case is expected to be using the MenuItemButton (or at least wrapping their widget in one), so maybe this isn't a huge consideration, but keeping that feature is why we made so many design iterations.

Option 1 could have additional use cases, such as in the case of popup menus, dropdown menus, or to simplify focus handling when modal dialogs or navigation occur. It may complicate the focus model further, however, which would definitely be undesirable, as it's already too complex. This is currently my preferred option, however.

cc @HansMuller @goderbauer