GUI declares input as handled only if it is really handled

[BimDav]

See #54529.

Input events were consumed by Control nodes as long as their filter was not set to MOUSE_FILTER_IGNORE. With this change they are consumed only if the Control handles the event or its filter is set to MOUSE_FILTER_STOP. Notably MOUSE_FILTER_PASS will not consume the event. Such unhandled event will then trigger _unhandled_input methods.

[golddotasksquestions]

Thanks you for this fix!!

[golddotasksquestions]

@akien-mga
Would it be possible to cherry-pick this fix for 3.4.1?
Besides #54529, I'm also having issues with mouse filter "pass" in my Control node only inventory and drag and drop scenes because pass is setting the input as handled. Issue documented here: #55432

Having to work around this bug is making my code very elaborate and complicated.

[golddotasksquestions]

@BimDav @YeldhamDev

Is this issue with Pass behaving like stop possibly related to this:
#55432

[BimDav]

Is this issue with Pass behaving like stop possibly related to this: #55432

I tested your project and sadly, no, this PR does not fix #55432, which is apparently related to input handling between Control Nodes. I will have a look at it soon.

[KoBeWi]

This isn't really a bugfix, because it changes established Control behavior. It breaks compatibility and might break lots of things if it resolves #55432 too.

But seems like the original behavior causes lots of confusion, so I wonder if changing it isn't maybe good.

[golddotasksquestions]

The intended use for "Pass" is not to behave like "Stop". Why would it? We already have "Stop" for the stop behaviour.
If "Pass" is expected by users to behave as the name indicates (to pass) and behaves like "Stop" it clearly is a bug. The fact that it is known behaviour to some, does not make it less of a bug.

[KoBeWi]

Except it does pass the input, but under different rules than most people think. So the only problem is that it's unexpected. Pretty sure there was a reason for the original behavior.

[BimDav]

Except it does pass the input, but under different rules than most people think. So the only problem is that it's unexpected. Pretty sure there was a reason for the original behavior.

I had the exact same reaction in #54529, but by looking at the code I was not able to find this reason, except that it was a little easier to do it that way. On the topic of breaking compatibility, I agree that it may cause some problems, so we may want to wait for 3.5 or even 4.0.

[golddotasksquestions]

Except it does pass the input, but under different rules than most people think.

Except when it does not. Like in #55432 or #54529

The definition of a bug is not when something works, but when it does not as it should.
Users don't need to care what the underlying reason for an implementation is. Either the feature works according to the design of it does not. Mouse filter "Pass" clearly does not work in a lot of situations as it should (from a user perspective).

If a programmer intentionally implements a feature in such a way it contradicts it's design and documents it, the code might work and be seen as "bug free" from the perspective of the programmer, but it still won't work and will be seen as a bug for the user as long as it contradicts the features purpose and design.

[groud]

Closing as superseded by #61088.
Sorry this was not reviewed in depth before (and I did not see it before working on my PR :/), as the new implementation is quite similar.