Viewport property "Handle Input Locally" gets set to false for no apparent reason, including in the editor, when it is a child of ViewportContainer.

[SnowboundCabin]

"Handle Input Locally" won't stay checked on 3.4.2-stable. The inspector will show the "revert to default" icon, but even if the property is manually written into the file as being explicitly true, it will always appear as false in the editor when you stop looking at the scene and look back. When running a project, checking it it during the ready function of the viewport's container will return false. Attempting to set it to true during the ready function succeeds, and getting it during the same function call returns true, but it gets reverted at some point between that and the first call of the container's process function, where it will return false. Calling the set function deferred from ready will not be reverted, however, nor will setting it at any point after that... Unless there's some trigger that'll cause it that I simply haven't tripped, like changing the viewport container size or something.

I have no idea why this would happen. Malevolent spirits?

Can be reproduced with the same project as in the below issue.

Originally posted by @SuperSuit12 in #25525 (comment)

[SnowboundCabin]

(I don't frequently open issues - hopefully I did this right.)

[SnowboundCabin]

Oh! And there's an old project I have where this issue doesn't come up... Perhaps because the viewports are added to the container a while after it's set up, rather than being part of the PackedScene?

[SnowboundCabin]

Confirmed previous comment - tried it in a separate project and it's DEFINITELY because of the ViewportContainer, not Viewports in general. So it seems... intentional? I would expect a little ⚠ in the SceneTree pane if it's set up in a potentially harmful way, but not forcefully setting the option like that. As far as I can tell, it works fine when set to true... Better than fine, even, because it being set to false results in some very strange behavior, like buttons not being clicked for no apparent reason because something visually behind them is getting the input first.

[Calinou]

handle_input_locally doesn't have documentation in either 3.x or master. This should be fixed, but I don't know how it works myself.

[SnowboundCabin]

I thought I'd mentioned this here, but apparently not... I checked, and it's very clearly intentional. There's a bit of code in ViewportContainer (at least in 3.x) that intentionally disables the option, labelled something along the lines of "don't do this." It appears to have been added in the commit the handle_input_locally property itself was. Git blame says @reduz wrote that, so he's probably the one to ask about how it works.

I'm not sure if it solves #25525. I'm not seeing any absolutely critical issues, and most of the time input goes to exterior elements as you'd expect. However, buttons inside the Viewport still enter the "hovered" state when there's something that should be blocking them, and I had the occasional issue with still clicking "through" an outside element to an inside one - although why the latter happens I can't discern, because I cannot figure out how to reproduce it. I had a couple of elements that were identical in all but position, and one got clicked through outside elements while the other did not. I switched their positions and rearranged them in the hierarchy a few times, and nothing changed, until I detatched the script from both to make sure it wasn't something about my custom input code. When I did that, the outside button always got the click, even when I undid the change - it's broken, detatch, detatch, it works, ctrl-z, ctrl-z, it still works despite the fact it should be in exactly the same state as it was earlier, when it didn't work.

[Nukiloco]

I just got this issue and spent couple of hours wondering why my viewport input was conflicting outside the viewport container.
Currently I have a script that just toggles it off then back on again just to fix it.

onready var viewport_node = find_node('Viewport')

func _ready():
	# Bypass for issue #56502
	viewport_node.handle_input_locally = false
	yield(get_tree(), "idle_frame")
	viewport_node.handle_input_locally = true

[Nukiloco]

https://github.com/godotengine/godot/blob/3.5/scene/gui/viewport_container.cpp#L123

Seems to be where the issue is happening. I turn handle_input_locally back on with a script and I just did quick test with gui nodes over the viewport. So far it seems to be just functioning fine?

I assume the reason why this is here is because the ViewportContainer handles all the input events by itself and send it to the viewport?

The reason why above I'm manually turning it off, since it seems to be taking gui input from nodes that are above it even though it shouldn't be able to do that. So really I guess this just #28833.
Or this could just be a general input issue with gui nodes since it seems like there is a lot of issues with them when it comes to input.

[lekoder]

The ViewportContainer will also silently change the update_mode depending on the visibility. I don't think it should do that, either.

[myyk]

I just ran into this issue of handle_input_locally being set to false after running the scene. This is really confusing behavior. I added this to my scene as a workaround and it seems to mostly work:

func _ready():
    sub_viewport.handle_input_locally = true