Kotlin's `==` on the proxy compiles to `proxy.equals(args[0])`, which
the JDK proxy dispatches back through the InvocationHandler, hitting
the same branch and recursing into StackOverflowError. Use `===` for
reference equality, matching the default Object#equals behavior.
Object.hashCode() must return Int (32-bit), but the proxy InvocationHandler
returned godotObjectID directly (Long, 64-bit). When a HashMap-like container
called proxy.hashCode(), the auto-generated proxy did (Integer) result on a
java.lang.Long and threw ClassCastException.
Signed-off-by: Muteem <29696635+Muteem@users.noreply.github.com>
JDK contract: InvocationHandler.invoke's args parameter is null when
the proxied interface method takes no arguments. The proxy handlers
in AndroidRuntimePlugin used `*args` directly, which spread-deref'd
null and threw NullPointerException.
Signed-off-by: Muteem <29696635+Muteem@users.noreply.github.com>
There are two "focus lost" signals in the Godot X11 display server:
1. `FocusOut` - native X11 signal
2. `NOTIFICATION_APPLICATION_FOCUS_OUT` - Godot signal after 250ms of
no other window getting focus.
When focus is lost, the intent is to clear any input pressed events so
that, when focus returns, we have a clean slate.
The bug is that the pressed events are (attempted to be) cleared on the
first signal, X11's `FocusOut`. This is always a no-op because it
returns early if the application still has focus. Godot's X11 server
only sets that flag after the second signal, not the first.
Move the pressed event clearing from the first signal handler to the
second. This makes clearing pressed events do what it says.
This does not affect Wayland because it does not have the 250ms grace
period.
Simple repro is to load any 3D scene, hold 'W' and, while 'W' is held,
click on any non-Godot window. Release 'W', click back to Godot, and
hold RMB. It will zoom forward as if 'W' is still pressed.
After the fix, the same test has RMB look around as expected when no
other keys are pressed.
Fixes#118897
Godot suppresses X11 BadWindow errors during some operations because
they can occur with normal usage.
X11 errors are asynchronous. Sometimes, when a BadWindow error is sent,
it is dequeued after the original non-BadWindow-suppressing error
handler has been restored. This results in an error callstack being
shown to the user.
Call `XSync` before restoring the original error handler. This ensures
that any queued BadWindow errors go to the suppressing handler.
Fixes#117814
Previously the Wayland display server would attempt to enable
HDR output and try to detect if it failed afterwards which had some issues.
Now we can query the rendering driver for support and avoid ever enabling
HDR output when this would fail.
The Wayland spec says:
> The compositor must send the wl_keyboard.modifiers event after this
event.
We did not during "fake" focus changes (e.g. from/to embedded
applications), effectively resetting the modifier state.
This patch simply tracks keyboard modifiers and informs clients whenever
we send custom enter events.
`DisplayServer::get_mouse_position` expects global values, but input
usually works in surface-local coordinates.
Previously, we queried WaylandThread directly and transformed the mouse
position when requested, which was somewhat racy. We now instead keep
track of the transformed position while dispatching input events (as the
whole context is there) and return that when requested.
Unlike Godot, Wayland doesn't have the concept of a single "mouse".
Because of this, we could easily emit "mouse enter/exit" events in weird
ways by e.g. using the tablet while using the mouse. This became even
easier to break with the addition of touch support.
This patch does its best to avoid this by tracking a single "hovered
window" and emitting events based on that. This logic is split between
`WaylandThread` and `DisplayServerWayland`:
* `WaylandThread` does all the "smart" tracking and makes sure that, as
long as there's *any* device pointing something, the hovered window will
be set to something. For example: if I have a pointer on a window and
quickly tap anything, the hover will switch to whatever is under the
pointer instead of getting unset once my finger lifts from the screen.
* `DisplayServerWayland` actually applies the hover change. This is
tricky as window event dispatching has side effects and might even
delete windows or change the hover itself!
Fredia Huya-Kouadio
Thaddeus Crews
Pāvels Nadtočajevs
Ivan Shakhov
Stuart Carnie
KOGA Mitsuhiro
Muteem
Leonard Pop
Michael Alexsander
Naoto Kondo
Anish Kumar
norepro
Aaron Franke
ArchercatNEO
Dery Almas