Repository: godot
Issue: Inconsistent partial mouse event handling for unfocusable windows
Labels: bug,topic:porting,topic:input

### Godot version

4.2beta5

### System information

macOS 14.1

### Issue description

While trying to build some custom interface controls that feature dropdown components (like a custom menu button popup with further controls) I've run into some issues and inconsistencies with the `unfocusable` property on Windows.

Allowing windows to popup without activating (as in not deactivating the current/parent window) is very useful for controls like dropdown menus, tooltips, hover-controls and such. However, the `unfocusable` property of Godot Windows has a couple of issues when used for this type of functionality:

When used on non-embedded windows it works as intended in that it does not deactivate the current window. However, the popup window controls do not get mouse move (enter/exit) or key events, but they do get mouse click events. As you can see below, the cursor change is also triggered, so the mouse areas are still tracked, but the controls don't get the enter/exit signals based on this.

https://github.com/godotengine/godot/assets/17763524/e4addaea-417e-455f-aff7-b1ad080b859c

Since the menu button menus also use this type of non-activating non-embedded window and they are able to track mouse enter/exit events on their items it must be technically possible in the engine. Perhaps these PopupMenu nodes have some special implementation to get around the regular `unfocusable` limitations?

When used on embedded windows it instead works the other way around. We now get mouse enter/exit events, but no click events for the controls in the window:

https://github.com/godotengine/godot/assets/17763524/73a749a2-b6a5-4c98-95f2-1c54d51a92d9

Reading the docs for [unfocusable](https://docs.godotengine.org/en/stable/classes/class_window.html#class-window-property-unfocusable) it states briefly that "If true, the Window can't be focused nor interacted with.".  If this is intended to include window content it is apparently not true in either case, but could explain why some events are blocked. 

However, in my mind that is not desirable either. The main use-case for having this type of window is I think for control popup components as explained above. And in these cases it's likely that you also want to get at least all mouse events. In other words that "unfocusable" should be clarified to mean that the window can't become the active window, but that the controls can still be interacted with in it. If you want to disable input in a window there is already a separate dedicated setting for this with the Window `Viewport.gui_disable_input` property.


### Steps to reproduce

- Set the project setting not to embed sub-windows
- Make a scene with a Window with unfocusable turned on
- Put a button control in the window
- Run and observe that you can click and press the button, but it does not respond to hover.

- Change the project setting to embed sub windows
- Run and observe that you can now get hover response on the button, but not click.

### Minimal reproduction project

[NonActivatingWindowsMouse.zip](https://github.com/godotengine/godot/files/13317876/NonActivatingWindowsMouse.zip)