Repository: godot
Issue: Right Mouse Button Behavior is Inconsistent with Standard Windows Behavior
Labels: feature proposal,discussion,topic:input

### Godot version

v4.1.1.stable.official [bd6af8e0e]  

### System information

Godot v4.1.1.stable - Windows 10.0.22621 - Vulkan (Compatibility) - NVIDIA GeForce GTX 1060 (NVIDIA; 30.0.14.7311) - Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz (12 Threads)

### Issue description

In Windows, mouse clicks that **activate** something like:
- Pressing a button
- Selecting a menu item
- Raising a context menu

All act on the _release_ of the button, not on the _press down_ of it.  You can test this yourself in any normal Windows application with a menu bar.  Activate one of the top-level menu items, and in the popup menu, _mouse down and hold_ on one of the items. You will not activate that menu item until you release the mouse button.  Additionally, you can mouse down on one item but then move to another one and then release the mouse button and you will activate the menu item the mouse is over at the time of the release.

Buttons have similar behavior - you can press and hold them, but they will not activate until you release the mouse button, and even then, only if you release the button while over the button.  This is what allows you to back out of an action if you accidently press the wrong button: all you have to do is move off of it before releasing the button and you will have effectively canceled the activation of that button.  (You may have even done this unconsciously yourself.)  Godot seems to have the behavior correct, BTW.

However, using the Right Mouse Button (RMB) to raise a context menu causes the menu to appear on the _down_ of the mouse button instead of the _release_ of it.  It also does the same thing with the context menu key on an extended keyboard.  The context menu should not appear until the mouse button is **released**, and the same goes for the content menu key.

Also, pressing the RMB during a Drag-and-Drop (D&D) operation does not work as expected, either.  The context menu appears but does not enter a standard _menu modal message loop_ so releasing the Left Mouse Button **commits** the D&D operation, but right clicking to activate a menu item causes the menu to reappear and breaks the connection between the mouse movement indicating the drop location in the editor as the caret location will update, but the drop location will be the caret's location when the context menu first appeared.

Pressing the RMB during a D&D operation should either _cancel_ the D&D operation, or it should be _ignored_ allowing the user to complete the D&D operation normally.  The latter is the standard behavior of most text editors in Windows, but for other D&D operations, using the _other mouse button_ will **cancel** the D&D operation.  You can verify this in apps like Windows Explorer and Outlook for example.

### Steps to reproduce

OK, so with a project loaded with at least one Node with an attached script, in the editor press but _do not release_ the Right Mouse Button (RMB).  The context menu will appear instead of waiting for the release of the RMB.  Try this again in whatever browser you are using to read this - the context menu appears on the _release_ of the button.

For the Drag-and-Drop (D&D) behavior, perform a valid D&D onto the editor but **do not drop** the item.  Press down the RMB button and hold it.  The context menu will appear and the caret in the editor will indicate a drop location.  While still holding down the Left Mouse Button (to continue the D&D operation), try to select a menu item with the RMB.  The context menu will just reappear at the new mouse location and the caret in the editor will move to match.  

If you try to commit the D&D operation after doing this, the text will get inserted at the earlier location when you first raised the context menu, not at the current location of the caret which is unexpected.

### Minimal reproduction project

N/A