Be more conservative with Mouse Filter defaults (most controls should have Ignore)

[Rybadour]

Describe the project you are working on:
A hobbyist game project involving a lot of UI work.

Describe the problem or limitation you are having in your project:
Given that most controls (including the generic Control node type) are set to mouse filter stop I am constantly surprised to discover my UI elements cannot be interacted with due to invisible boxes overlapping them.

Describe the feature / enhancement and how it helps to overcome the problem or limitation:
I'd recommend all nodes to have mouse filter pass or ignore unless they them-self implement an interactable UX. Container type nodes should not have mouse filter stop unless they are intended to overlap other content such as a popup.

Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:
I may misunderstand how exactly pass works but I would expect containers to have the behaviour that they will allow children to handle mouse events by default. If setting containers to ignore is problematic than either pass should be used or a new type should be created.

If this enhancement will not be used often, can it be worked around with a few lines of script?:
It can be "worked around" by constantly changing all nodes to mouse filter ignore. I am tempted to do so with a plugin. But I believe this change will make things easier for everyone.

Is there a reason why this should be core and not an add-on in the asset library?:
See above.

[TheDuriel]

As mentioned in #881 , I would say PASS as the default is more desirable. Otherwise we get similar situations to before, where inputs are not being recognized by Nodes when the user would expect otherwise. (Say you listen to input_event in a Control set to Ignore.)

[Xascoria]

If a scene have UI elements mixed with pickable PhysicsBody, it will often cause issues because Controls Node have mouse clicks priorities, and a lot of will eat the inputs even with PASS, as PASS doesn't pass the inputs to non-controls nodes. This is a very common problem.

Also it just makes 0 sense for ColorRect and TextureRect to be STOP as default at all, since most people use them for shaders.

[vonagam]

There are currently three options for mouse_filter:

• MOUSE_FILTER_STOP - process events, hoard them to a node even if unhandled.
• MOUSE_FILTER_PASS - process events, hoard them to a node's branch even if unhandled.
• MOUSE_FILTER_IGNORE - do not process events, do not hoard.

Why there is no MOUSE_FILTER_PROCESS or something which does allow processing events with _gui_input but does not block anybody else (behind or above in a hierarchy) from processing it too unless it was handled? To me that would seem an appropriate default behavior.

MOUSE_FILTER_IGNORE as a default will be a little too annoying too - a script defining _gui_input will need to change mouse_filter on each node that it is attached to for it to work.

If implementing MOUSE_FILTER_PROCESS is too hard then MOUSE_FILTER_PASS is a better alternative then others for being default.

[TheDuriel]

You have misunderstood MOUSE_FILTER_PASS . It does what you are saying process should do.

[vonagam]

MOUSE_FILTER_PASS does allow its parent to react to an unhandled event, but not its siblings which are behind, that what I mean by "hoard them to a node's branch".

But I suppose that implementing MOUSE_FILTER_PROCESS is too hard for its worth.

MOUSE_FILTER_PASS is a definite improvement over MOUSE_FILTER_STOP as a default and it does not require much to make it so. So I do not understand why the default was not changed already.

[TheDuriel]

It is implicit that any siblings will also receive the event if no parent eats it. That is the normal course of input propagation. Please don't spread misinformation in a topic that isn't about what the process modes do, but where they are meant to be used.

This proposal wasn't addressed because nobody could be bothered to do so yet.

[vonagam]

don't spread misinformation

There must be misunderstanding somewhere. This is about mouse_filter and _gui_input. Example scene:

Control (full rect preset, mouse ignore)
- Button (full rect preset, optionally with script and `_gui_input`)
- Control (full rect preset)

Unless child Control has mouse filter to ignore, button will never receive a gui event (as in react to mouse movement or get call to _gui_input). Am I missing something?

[TheDuriel]

If the Child has mouse filter mode set to Pass, the button will receive the event just fine.

[vonagam]

It will not and it is easy to verify with the provided snippet, this is how current architecture works. I am using Godot 4 from master. If you would like to continue this discussion I think it is better to use developers rocket chat for that.

As I understand we both agree that MOUSE_FILTER_PASS is better default one and that is the important part for this proposal.

For record, even if theoretical MOUSE_FILTER_PROCESS was present, I do think now that MOUSE_FILTER_PASS is better one.

[Sauermann]

An assessment of the current state is available in #3613.

[kitbdev]

Since I couldn't find this info in the documentation,
Here is a list of current defaults as of 4.2:

PASS:

• All Containers except PanelContainer
• TextureRect
• TextureProgressBar

IGNORE:

• Label
• NinePatchRect

STOP:

• Control
• PanelContainer
• All BaseButtons
• TextEdit and CodeEdit
• ColorRect
• RichTextLabel
• GraphEdit
• both ScrollBars
• both Sliders
• ProgressBar
• SpinBox
• both Separators
• ItemList
• LineEdit
• MenuBar
• Panel
• ReferenceRect
• TabBar
• Tree
• VideoStreamPlayer

These are the Controls that are currently STOP but don't handle any input themselves and I think should be changed to PASS by default:

• Control
• ColorRect
• ProgressBar
• both Separators
• ReferenceRect

Panel and PanelContainer seem to be intentionally set to STOP by default.
I don't think VideoStreamPlayer should be PASS by default, but I haven't used it.

Of course, this breaks compatibility so it probably won't happen for a while.

[EchoingLogos]

What is the reasoning for the base Control node being set to stop by default? This caused me many headaches in the past until it happened enough that I was able to identify the problem. I believe if the user wants a mouse blocker and not a generic control, they should have to specify that explicitly. RichTextLabel and Label having different mouse handling defaults is also problematic.

I also suggest against using Pass by default pretty much anywhere simply because the way it actually works is not intuitive as evidenced by the other proposal to rename it. In addition, I subjectively just don't understand why I should expect input to be passed to the parent rather than to whatever node is behind. A click feels like a laser shot through the screen that is captured by whatever is in front, and I don't see why that laser should care about the scene tree instead of the rendering order.