In T57856#554407, @Philipp Oeser (lichtwerk) wrote:

Cant oversee all consequences of consuming all (future) events when closing a menu [if I understand correctly the RELEASE -- or still holding "S" in my case -- are future events] if that is desired, or how hard implementing that would be.

I don't see this as a bug. It's more of a well hidden UI flaw. I can't think of any practical situation where a user would want to use a keypress to select an item in a menu and execute a function outside the menu context with the same key released.

A single key press always involves a "Press" event and a "Release" event. It's unavoidable. It is not a "future event". It's a "has to happen event" when a "Press" event is heard. A key will always have to be "Released" from a "Press" event.

Again, if this also happens when the hotkey isn't to execute on "Release", then this is very much an input bleed between "Menu" and "Editor Context". I think input should not bleed between a menu/pie menu and other contexts.

However, if someone can come up with one practical use case of this, I'd gladly listen.

This essentially drives fear into the act of changing hotkeys to "Release" state. <-- The
"execute on release" is otherwise extremely useful. I wouldn't mind demonstrating what they can do if anyone's curious.

With extreme customizability and flexibility, it's possible to create keymaps and interfaces that are completely broken. It's hard to prevent these kinds of issues. While I'm of course sympathetic to this, I'm not sure if this is technically a bug, or simply a keymap conflict that the user is able to create, and thus end up with a broken paradigm.

Not entirely sure how to handle these kinds of reports - I would tend to agree that this is actually a feature request, not a bug.

Not entirely sure how to handle these kinds of reports - I would tend to agree that this is actually a feature request, not a bug.

Whether it's a bug or a design flaw, I think it should not be left as is. I didn't know what type of report this should be, it feels like a flaw nonetheless, so I picked "bug".

If there are any suggestions on where to look in the source code, I'm tempted to try to change this so the inputs used to activate menu/pie menu items would execute on "Release", therefore maybe it won't bleed into the underlying context at all, or less often.

If that doesn't work, maybe there is a way to ignore the "Release" event in the menu after a "press" event.

In T57856#554622, @Brecht Van Lommel (brecht) wrote:

There are thousands of these little things that could be improved. Realistically this is so low priority it's unlikely to ever be solved.

But mainly, this tracker is purely for bugs, and I don't consider this one.

I believe this falls into the "Unintended design behavior" category. If no one cares, I'd like to research how to improve this. It would be greatly appreciated if there is anyone who's familiar with Blender's source code that deals with inputs and menus that could point me towards the related sections of the codes.

I'd really recommended not to try to fix this, there may be no clean solution given Blender's event handling design, and trying to find a clever solution is likely to introduce bugs. There are many more important things to fix, like T56950: UI Paper Cuts (Parent Task).

In T57856#554859, @Brecht Van Lommel (brecht) wrote:

I'd really recommended not to try to fix this, there may be no clean solution given Blender's event handling design, and trying to find a clever solution is likely to introduce bugs. There are many more important things to fix, like T56950: UI Paper Cuts (Parent Task).

Some of the papercuts like these ones:
T57685: Add Save Before Closing to File -> New & File -> Open
T57746: Outliner: Dragging over disclosure triangles moves item rather than opening/closing
are probably more important than the problem I suggested. Others, in my honest opinions, doesn't matter, that's why they are called "papercuts" anyway.

I worry more about bleeding wounds like inputs for selecting items in menus that bled onto the next context when menu closes.

Really, it's workflow interrupting, and it prevents users from utilizing the full potential of Blender's hotkey system, plus occasionally introduces some unintended behaviors. (from a user's perspective)

I have a few thoughts about how I can negate the problems without changing how input events are handled by Blender.

1. Based on my assumption, Blender's menus generates the hotkeys for selecting menu items automatically. If I could experiment with how these are generated, I could find a way to solve the issue. In the worst case scenario, I can at least add an option in user-preferences to turn off "auto-generate-hotkey" for menus, or change menu options to activate only on hotkey "Release" and block off all inputs to other contexts when a menu is open. This way, when the menu closes, user input for the menu has already ended, whatever happens after should match the user's intention.
2. Blender's operators do have a 'bl_option' called {"BLOCKING"}, it blocks all non-modal input. This mechanism may be used for Menu Types to solve input bleeding. Though, I'll have to experiment more with this, since I don't know whether it is possible to leave the "auto-generated-hotkey" alone while blocking all other inputs.

If I can get this issue fixed, I'd gladly help to fix all the papercuts for the masses.

The thing is binding an operators to release is basically never what you want. We only need the release event in some modal keymaps. It is more a UI issue in key configuration than anything else.

Solution 1) is not acceptable, we do not want to make menu interaction slower than it needs to be. And menus are not like modal operators, so 2) will not work.

I just realized one possible problem of executing items on release. If a pie menu is executed by pressing S, and an option in it responds to S on release, then I move my mouse on a different option that's activated by a different hotkey, now releasing "S" key will have 2 possible outcomes, they might be fighting for priority. Or, even if I don't want to select any options, it would execute the option that's tagged with "S".

Combined with what you said, I think my methodology in configuring hotkeys is actually flawed. It is for the best to avoid mapping operations to execute on release unless it is absolutely necessary or it's part of the design.

Thank you for responding to my ideas and suggestions, if it weren't for the discussion I may have never realized the flaws in my methodology.