Container doesn't recognise mouse_enter

[Cobradabest]

Operating system or device - Godot version:
Windows 10, Godot v2.1 stable

Issue description (what happened, and what was expected):
When using mouse_enter with a container, the container only recognises the mouse at a very specific and small spot

Steps to reproduce:
Create a container item and create a script containing the mouse_enter flag

Link to minimal example project (optional but very welcome):
https://www.dropbox.com/s/vvfwhlu2xvyo0mu/Test.zip?dl=0

[mateka]

I guess that container is almost hidden under menu item and gets mouse events only in tiny parts, which are not hidden by child control. In my opinion, everything is working alright.
You can set flag Ignore Mouse to ignore mouse events if You only need to animate item.

[bojidar-bg]

@Cobradabest Can you confirm that what @mateka suggests works/doesn't work so that we can close the issue?

PS. I agree that it probably gets hidden by child nodes that have Ignore Mouse off.

[bojidar-bg]

@Cobradabest Pretty ping 😄

[ghost]

Okay I just tested this out.

Going to agree with @mateka here. Basically this is not isolated towards Container nodes, but actually any node that inherits a Control class. It's just how Godot's mouse capturing seeps it way through

For example, if you have a hierarchy like this:
Control -> Panel -> Button

And set a mouse_enter signal for the control. It will not trigger that signal if your mouse is above the panel or button. However, if you set Panel and Button's ignore_mouse property (focus/ignore_mouse) to true, then the mouse_enter signal for control will fire.

Is this intended or normal behavior?

I think it's just how Godot works. However, ideally, I think if the children have a parent that has a mouse_enter signal (like above) it should still emit the mouse_enter signal. Because technically you are hovering over that node.

However again, this also allows for rich UI development. Because you can set the focus/ignore_mouse property and have tons of children doing a bunch of crazy shit without their own children affecting it (if that child has a mouse_enter signal attached)

Double edge sword

[ghost]

However, now that I think of it I'm wrong.

Conrol -> Panel -> Button

Set a mouse_enter signal for Control. Hover over the panel / button and it will not fire. Set the Panel's focus/ignore_mouse property to true, now hover over the button and the signal will fire.

But, what if you want to have Button use the mouse? You cannot because you set the focus/ignore_mouse property to true.

Maybe we should allow the children of a mouse_enter signal'd Control node to emit its parent Control node signals? Because technically, the mouse is still hovering over them... Hmmm

[voithos]

The way this is done in Web APIs (JavaScript et al) is via event "bubbling" - i.e., in the default case, events triggered on child elements/controls will trigger handlers, if present, on both the control as well as all parent nodes. (Most events behave this way, but not all - for example, the focus event is only triggered on the element that has the actual focus, and does not bubble)

In some cases, a more specific handler (say, on Button) would want to prevent parent handlers (e.g. on Panel) from firing, and in the case of Web, there is a method on the event object that does this: event.stopPropagation()

With bubbling as described above, I'm not sure what focus/ignore_mouse would be used for (does it have other purposes besides disabling event capture?).

[ghost]

First of all thank you for your report and sorry for the delay.

We released Godot 3.0 in January 2018 after 18 months of work, fixing many old issues either directly, or by obsoleting/replacing the features they were referring to.

We still have hundreds of issues whose relevance/reproducibility needs to be checked against the current stable version, and that's where you can help us.
Could you check if the issue that you described initially is still relevant/reproducible in Godot 3.0 or any newer version, and comment about it here?

For bug reports, please also make sure that the issue contains detailed steps to reproduce the bug and, if possible, a zipped project that can be used to reproduce it right away. This greatly speeds up debugging and bugfixing tasks for our contributors.

Our Bugsquad will review this issue more in-depth in 15 days, and potentially close it if its relevance could not be confirmed.

Thanks in advance.

Note: This message is being copy-pasted to many "stale" issues (90+ days without activity). It might happen that it is not meaningful for this specific issue or appears oblivious of the issue's context, if so please comment to notify the Bugsquad about it.

[akien-mga]

Closing as old. If the original issue is still valid in the current master branch / latest stable release, please comment here or open a new issue.

[trommlbomml]

@akien-mga I can confirm this behavior and I think we should talk about this again, I would like to explain my use case and why event bubbling would solve this properly and simple:

I have the following hierarchy, anchored center right:

• CanvasLayer
  • VBoxContainer
    • Button
    • Button
    • Button
    • Button

The CanvasLayer is offsetted by VBoxContainer.RectSize.x - 20, so a little bit is visible. When the VBoxContainer gets OnMouseEntered(), I animate the Canvaslayer to see the full buttons, when the VBoxContainer gets mouseleft(), the menu should animate back to the right initial state, done via tween. So I have a neat sliding menu on hover.

As The event is not bubbled to the parent I would need to manually wire up the events from each button (or child control!) and emit a signal manually on the parent, so that the canvas layer can animate properly. It would be really helpful to at least activate kind of signal bubbling manually with a flag.

[Calinou]

@trommlbomml See various proposals on this subject: godotengine/godot-proposals#788, godotengine/godot-proposals#1322

[trommlbomml]

Thx, then this issue can stay closed.