Sub - viewports still don't handle _unhandled_input or CollisionObject._input_event()

[JPTeasdale]

---

Bugsquad note: This issue has been confirmed several times already. No need to confirm it further.

---

I noticed in PR #15712 the _input event is forwarded to explicitly created Viewports, but _unhandled_input and CollisionObject._input_event() still don't respond

Godot version:
3.0.stable.official

OS/device including version:
OSX 10.13.2 (17C88)

Issue description:
The only input events that propagate into sub-viewports are _input.

_unhandled_event and _input_event (for Area2D etc) do not get called.

Steps to reproduce:
Open the attached Godot project and run it.

The Red area is in the default Viewport and receives all click events.
The green area is a child of the explicit viewport and only receives _inputevents.

Minimal reproduction project:
ViewportInputBug.zip

[bojidar-bg]

CC @Faless

PS. @JPTeasdale, can you try following the issue template for this and future bugs? It is hard to guess your version and OS otherwise 😃 Also, it would be nice to have a simple project which reproduces the bug, in order to help hunting it.

[JPTeasdale]

Ahh, sorry about that. I thought since I included the link to the source where _unhandled_input etc wasn't implemented it would be enough. I'll hydrate the bug report when I get home.

…

On Thu, Mar 8, 2018 at 2:42 AM Bojidar Marinov ***@***.***> wrote: CC @Faless <https://github.com/faless> PS. @JPTeasdale <https://github.com/jpteasdale>, can you try following the issue template for this and future bugs? It is hard to guess your version and OS otherwise 😃 Also, it would be nice to have a simple project which reproduces the bug, in order to help hunting it. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#17326 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABQzLzYOcPF7fiiaAqdMKTNrnYvTrL2Nks5tcQUGgaJpZM4Sf8tz> .

[letheed]

Was wondering why input wasn't working on subviewports. Has this fallen off the radar? Is the fix for _unhandled_input just a copy/paste of #15712?

[Faless]

Is the fix for _unhandled_input just a copy/paste of #15712?

Sadly no, it needs some more work to get object picking to work properly. I tried a fix at some point, but never got it right.

Has this fallen off the radar?

A bit :(

[letheed]

@Faless Ah I see, keyboard is easy enough to do manually so that's all right. I was just a bit surprised because the doc said ViewportContainer + Viewport handled input automatically.

[Xrayez]

As a workaround I've found doing this:

extends ViewportContainer

func _unhandled_input(event):
	$Viewport.unhandled_input(event)

seems to solve the issue (at least for CollisionObject._input_event())

So perhaps the fix can be copy pasted after all?

[voxelv]

@Xrayez, unfortunately your workaround didn't work for me, as I'm trying to use Node._unhandled_input() under the Viewport (rather than CollisionObject._input_event() as you mentioned).

I'm just getting into Godot, and after about 3 months of fiddling around, the ViewportContainer and Viewport nodes are the correct solution to the functionality I'm trying to implement, but this flaw (that _unhandled_input() is not propagated correctly) is keeping it from being successful.

[mysticfall]

Yes, I can confirm that the suggested workaround doesn't work for the master branch. I had to move event handling code out of the viewport to mitigate the problem but it'd be nice if we can have a proper fix soon.

[NightGriffin]

I made it works by copying #15712 and changing it to unhandled_input so that setting the viewport container mouse filter to ignore generate physics picking event with the correct position (which forwading event by the way of the script doesn't). I am sad that it is not the proper fix but it can help peoples desperate like me while waiting for the proper fix.

[voxelv]

I'm curious what the "proper" fix is. I've looked at the code and understood about 20% of how events propagate through the stack, and unfortunately I'm just not familiar enough with the project. Can anyone explain how the problem is supposed to be solved?

[reyalpsirc]

Any news on this or any good way to work around this issue with the Viewports?

[reyalpsirc]

Okay, it seems that I made it work with this in my case:

extends ViewportContainer

func _input(event):
	$Viewport.unhandled_input(event)

And then set Disable Input and Object Picking to true on the Viewport itself

EDIT

Actually if seems that Disable Input can be false for my case but, I still need Object Picking as true

[NightGriffin]

From what I have seen it only works when the ViewportContainer is at 0,0 (upper left corner)

…

On Thu, Sep 27, 2018, 4:39 PM Cristiano Santos ***@***.***> wrote: Okay, it seems that I made it work with this in my case: extends ViewportContainer func _input(event): $Viewport.unhandled_input(event) And then set Disable Input and Object Picking to true on the Viewport itself — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#17326 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFFXbh6gjmgYVslgbZ_wgiOxwRSBCeRMks5ufWHFgaJpZM4Sf8tz> .

[Faless]

@NightGriffin yes, which is partly the reason why this is not trivial.
Only unhandled input over the viewport should be passed down.
Object picking should probably then block any further propagation to other ViewportContainers (eg, if one viewport is partly on top of another).
Input should be properly xformed to match the actual scale/pos of the viewport.

[ArdaE]

Here's a little improvement to @reyalpsirc's temporary solution to fix the issue @NightGriffin raises, until this is supported by the engine:

extends ViewportContainer

func _input(event):
	if event is InputEventMouse:
		event.position -= rect_global_position
	$Viewport.unhandled_input(event)

[ArdaE]

Looks like the event object is used by other nodes after the _input call returns, so modifying its position messes up other controls. Here's a better workaround for the issue:

extends ViewportContainer

func _input( event ):
	if event is InputEventMouse:
		var mouseEvent = event.duplicate()
		mouseEvent.position = get_global_transform().xform_inv(event.global_position)
		$ClassesViewport.unhandled_input(mouseEvent)
	else:
		$ClassesViewport.unhandled_input(event)

Note that this is a temporary workaround until a proper fix is implemented in the engine. It works for me, but may not for you. I wouldn't leave it in released code. Although I don't know the full design behind input handling in Godot, it seems weird to call unhandled_input from _input, but it does the job for now.

[reduz]

It seems unhandled input was simply not being passed. I will add code so it gets passed, you will have to remove your hacks though.

[EstevanBR]

I"m seeing this issue in 3.1.1 maybe im doing something wrong?

[YeldhamDev]

@EstevanBR I opened a new issue here: #31802

[FeralBytes]

@EstevanBR I can confirm it seems to be fixed in 3.2.0a2 available here.

[GameDevLlama]

I still got this issue when using ParallaxBackgrounds. I wanted to use Area2D and mouse enter / exit signals in a Layer in ParallaxBackground and it also won't propagate mouse events correctly

[evelant]

This is still an issue. I had to use the workaround in #17326 (comment)

[Reituag]

Hi everyone, I'm using Godot 3.4.2 on windows and I need to use this solution from @ArdaE to make it work.
Is there any definitive solution ?

[Flavelius]

When someone attempts a fix, please also address being able to disable input handling for all nodes inside a viewport.
I need/use it in my project, and this bug is actually a way to make it work, as i can decide whether to pass the unhandled event down (atleast it seems to work as expected in my case) from the manual override that currently is the fix.
This is what i currently use and ideally don't want to lose in functionality when this is fixed:

extends ViewportContainer

var world: Viewport

func _ready():
	world = get_child(0)

func set_active(state:bool):
	visible = state
	world.gui_disable_input = not state
	world.set_process_input(state)
	world.set_process_unhandled_input(state)
	world.set_process_unhandled_key_input(state)

func _unhandled_input(event):
	if not visible:
		return
	world.unhandled_input(event)

[ashifolfi]

Can someone help create a C# version of the fix in #17326 (comment) ?
This issue seems to still be present in Godot today and I can't seem to figure out how to properly convert this into C# for my project.

I need to also be able to check certain variables before passing the input over.

EDIT: I ended up figuring it out

[FeralBytes]

@ashifolfi then please post your fix, as it could help others like you in the future. Thank you.

[WolfgangSenff]

I believe there may be a regression for this in at least 4.2.beta5. I'm running into the issue when attempting to drag-and-drop a control into a subviewport. I have downloaded the repro project for the larger parent issue (#57894) and several of the tests are broken in the latest beta. I've looked at the code as well, and it seems like at least the code for this fix is either missing or only partially present, and this bug is part of a larger series of bugs that were previously all fixed at once - I didn't have time to check all of those.

[Sauermann]

@WolfgangSenff yes, this is a known issue, reported in #84258 and there is a PR open to fix this issue: #77926