Predictive back gesture does not fire keyUp event

[LobbyDivinus]

Describe the bug

PR #7429 added support for predictive back gestures. That is a special way of triggering the back key via a gesture on Android. In contrast to the previous implementation - and my expectation on how it would work - it does not fire a keyUp event.

From my understanding the solution would be to also fire a KEY_UP event in the OnBackInvokedCallback.onBackInvoked() implementation:

libgdx/backends/gdx-backend-android/src/com/badlogic/gdx/backends/android/DefaultAndroidInput.java

Lines 1420 to 1425 in 32eb91a

	KeyEvent event = new KeyEvent();
	event.timeStamp = System.nanoTime();
	event.type = KeyEvent.KEY_DOWN;
	event.keyCode = Keys.BACK;
	event.keyChar = 0;
	keyEvents.add(event);

Reproduction

The main difficulty may be to know if your device is even using predictive back gestures.

Here's a setup to create a test bed:

    Gdx.input.setCatchKey(Input.Keys.BACK, true)
    Gdx.input.setInputProcessor(new InputAdapter() {

        @Override
        public boolean keyDown(int keycode) {
            Gdx.app.debug("input", "keyDown: " + Input.Keys.toString(keycode));
            return true;
        }

        @Override
        public boolean keyUp(int keycode) {
            Gdx.app.debug("input", "keyUp: " + Input.Keys.toString(keycode));
            return true;
        }

    });

On my test device (only using gesture back button) it outputs:
[input] keyDown: Back
[input] keyDown: Back
[input] keyDown: Back
...

While I would expect it to output:
[input] keyDown: Back
[input] keyUp: Back
[input] keyDown: Back
[input] keyUp: Back
[input] keyDown: Back
[input] keyUp: Back
...

version

1.13.0+

Affected platforms

• Android
• iOS
• HTML/GWT
• Windows
• Linux
• macOS

[Frosty-J]

I agree. What I observed from my devices, testing with a native Android app, is that ones with physical or capacitive back buttons repeat the keydown event for as long as it is held, followed by keyup, whereas if you have a navigation bar the keydown event only gets repeated a single time (when it turns from a regular press into a long one). Again, followed by keyup on release - that much is consistent.

In API 33, predictive back was either invoked or it wasn't, but as of API 34 we can use OnBackAnimationCallback which extends OnBackInvokedCallback's capabilities. See the following docs:

public void onBackStarted (BackEvent backEvent)
Called when a back gesture has been started, or back button has been pressed down.

public abstract void onBackInvoked ()
Called when a back gesture has been completed and committed, or back button pressed has been released and committed.

So it would seem we have a direct equivalency to down and up. But would implementing it like that catch developers out? Where a dev using keydown could lead to users accidentally going back if they start then cancel back gesture. It's also still only a binary state we'd be exposing, whereas the API allows us to get back gesture progress and some other stuff, for example to fade between screens.

[LobbyDivinus]

Thank you for the insights. I think firing keyDown in onBackStarted would be counter intuitive in countless existing apps. Also, it's not a nice semantic as there's still the option for it to not be invoked leading to missing keyUp (again, hm).

What I noticed is that apps like Chrome don't do scrolling once you initiate a back gesture, whereas in libGDX we still receive touch events normally. This can lead to strange behavior as we don't want app interaction (like tap and scrolling) when trying to go back.

Not sure where this is going. To me it sounds too specific to expose it to the general interface of Input. Instead, I'd prefer DefaultAndroidInput to be more easy to extend eg by moving PredictiveBackHandler creation into a protected method. The default behavior should be something like:

• fire keyDown and keyUp once in onBackInvoked
• not process touch input during events onBackStarted - { onBackInvoked, onBackCanceled }

This would be compatible with existing behavior while addressing accidental app interaction.