Right mouse click up causes app to prematurely exit on certain Android platforms

[SDLBugzilla]

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• patch for multiple buttons at the same time not working (multiple_buttons_at_the_same_time_on_android_patch.diff, text/plain, 2016-01-14 20:06:10 +0000, 2954 bytes)

Reported in version: 2.0.8
Reported for operating system, platform: Android (All), ARM

Comments on the original bug report:

On 2016-01-09 02:07:39 +0000, Anthony @ POW Games wrote:

This bug doesn't affect all Android platforms. I've tested it on 4.1.1 and 4.2.2 and it causes the app to close when the right mouse button is released - no events, no warning, no chance to intercept. I've noticed that the right mouse button down doesn't produce any mouse button events although, other mouse buttons work as expected).

This bug doesn't affect Android 4.3 (I've only managed to test on 3 physical devices so far), so it seems to affect older tablets, but everything works perfectly on my phone (4.3). So it appears to be an API issue. Not debilitating, but annoying.

On 2016-01-09 19:46:49 +0000, Philipp Wiesemann wrote:

Does setting SDL_HINT_ANDROID_SEPARATE_MOUSE_AND_TOUCH make a difference?

On 2016-01-11 02:51:48 +0000, Anthony @ POW Games wrote:

SDL_HINT_ANDROID_SEPARATE_MOUSE_AND_TOUCH doesn't affect the bug, but...

Digging deeper I found that a SDL_MOUSEMOTION event is generated on right mouse button down and up, before application prematurely terminates, but not SDL_MOUSEBUTTONUP or SDL_MOUSEBUTTONDOWN.

On 2016-01-11 19:09:48 +0000, Philipp Wiesemann wrote:

Two Android mouse buttons were not mapped to SDL mouse buttons. This might have been the reason that there was a motion event without a button event.

The mapping was added here:
https://hg.libsdl.org/SDL/rev/0052384f717f

On 2016-01-11 19:34:46 +0000, Anthony @ POW Games wrote:

Thanks - that's a good patch. Tried it but no change, still only movement events and no button events.

Just to clarify: the same physical mouse right button will work on some platforms (4.3), but causes this bug on others (4.1.1 & 4.2.2).

On 2016-01-11 23:23:43 +0000, Anthony @ POW Games wrote:

Just to add more thoughts to the pot:

The physical right mouse button behaviour in non-SDL2 apps behave like pressing the back button across all versions of Android that I have tested. So if I were to guess, it might be something changed in the API at level 18 that SDL is missing. I would need to test on more versions to shed more light though.

On 2016-01-12 12:10:17 +0000, Anthony @ POW Games wrote:

I've found the problem. I'm completely new to bugzilla, Mercurial and Java, so bare with me please.

On API level <14 the only mouse button according to the activity is a left mouse button. The kernel invokes onBackPressed() when the right mouse button is pressed. SDL2 doesn't catch this in any way, hence the application closing prematurely. There is no way to intercept this in SDL2.

The solution is to add:

@OverRide
public void onBackPressed() {
/* generate a fake right mouse button event here ?*/
}

to SDLActivity.java.

I've tested it and it stops the app from closing prematurely. As far as I can tell, the only time OnBackPressed() will be called is when the right mouse button is pressed, so it's safe to assume this and generate a fake right mouse button event. In all other cases, it seems all the mouse buttons and back buttons are caught correctly by SDL2 and converted into the corresponding events.

Would someone be able to confirm and action this change?

Ryan: if you're listening, would this affect this fixme in SDLActivity.java? "FIXME: dump this SDK check after 2.0.4 ships and require API14.".

On 2016-01-12 18:18:02 +0000, Philipp Wiesemann wrote:

Android's MotionEvent documentation has a note that the system may send KEYCODE_BACK events for BUTTON_BACK.

It would make sense that in this case the KeyEvent would be of SOURCE_MOUSE instead of SOURCE_KEYBOARD. The method onKey() in class SDLSurface (in "SDLActivity.java") would get the event but ignore it because it is not of SOURCE_KEYBOARD. It would return "false" and the event would therefore be handled by the system. And the system calls onBackPressed() by default.

This would mean that not handling a KEYCODE_BACK event would be the actual fault.

On 2016-01-12 18:42:44 +0000, Anthony @ POW Games wrote:

Yes, temporarily changed onKey() to return true, which stops the app closing on right mouse button.

So, what's the best way to fix this?

On 2016-01-12 20:24:09 +0000, Philipp Wiesemann wrote:

Maybe a "translation" of the key event into a mouse event could be added in onKey().

Something like (does not compile):

    if ((event.getSource() & InputDevice.SOURCE_MOUSE) != 0) {
        // On some devices key events are sent for mouse BUTTON_BACK/FORWARD
        int action = event.getAction();
        int mouseButton = -1;
        if (keyCode == KeyEvent.KEYCODE_BACK) {
            mouseButton = MotionEvent.BUTTON_BACK;
        } else if (keyCode == KeyEvent.KEYCODE_FORWARD) {
            mouseButton = MotionEvent.BUTTON_FORWARD;
        }
        int mouseAction = -1;
        if (action == KeyEvent.ACTION_DOWN) {
            mouseAction = MotionEvent.ACTION_DOWN;
        } else if (action == KeyEvent.ACTION_UP) {
            mouseAction = MotionEvent.ACTION_UP;
        }
        if ((mouseButton != -1) && (mouseAction != -1)) {
            SDLActivity.onNativeMouse(mouseButton, mouseAction, ...);
            return true; // because event was handled
        }
    }

"SDL_androidmouse.c" would need to be adapted to handle an event without mouse coordinates.

On 2016-01-12 20:31:00 +0000, Philipp Wiesemann wrote:

There is another problem with the current implementation which maybe should be fixed first (to prevent some work). It was written as if it would get the number of a button from the Java side but actually it gets the state of all buttons. That is why it should not work if more than one button is pressed at once.

For the workaround here, this information is not available. Only if BUTTON_BACK or BUTTON_FORWARD was pressed. So the implementation needs to be fixed to provide the state of the remaining buttons (though the workaround might not be needed on devices where pressing more than on button actually works :).

On 2016-01-12 23:01:14 +0000, Anthony @ POW Games wrote:

Philipp, I came across the same problems when attempting to hash my own fix. For now, I'm calling my own fake right mouse button NDK C function from onBackPressed().

What usually happens now? Does someone volunteer to make a patch? I don't have the authority; I'm completely new here.

On 2016-01-13 06:43:44 +0000, Ryan C. Gordon wrote:

(In reply to Anthony from comment # 11)

What usually happens now? Does someone volunteer to make a patch? I don't
have the authority; I'm completely new here.

If someone makes a patch, post it right here with the "Add an attachment" link and we'll see what the best route to getting it into SDL is from there (it might be good and we apply it right away, it might need little changes, etc).

--ryan.

On 2016-01-13 18:48:06 +0000, Philipp Wiesemann wrote:

The simple fix was added here:
https://hg.libsdl.org/SDL/rev/d710a7a66aa5

It should fix finishing the Activity on the devices with API 16 and 17 (said to be the ones with the problem) and the right mouse button should do nothing now.

To improve this and get mouse events from key events, the handling of multiple buttons should be fixed first (I think, see above :).

On 2016-01-14 20:06:10 +0000, Philipp Wiesemann wrote:

Created attachment 2365
patch for multiple buttons at the same time not working

The attached patch may fix the mouse events and state if more than one button was pressed at the same time.

This limitation was already noted in bug 1666 and there seem to have been no complaints since then (which could mean that the functionality is not used or somehow not broken at all).

I did not (can not) test this patch (but it compiles and also could work if I understood the documentation correctly).

There was no new Bugzilla entry created for this patch because I think that it is related enough to bug 3227 here.

On 2017-08-12 15:06:54 +0000, Sam Lantinga wrote:

This patch is added, and the original bug should be fixed.
https://hg.libsdl.org/SDL/rev/11c69137bfd5

Please let me know if the original bug needs more work!

On 2018-04-20 22:48:02 +0000, Anthony @ POW Games wrote:

Hi again guys, I'm back after 2 years unable to use the Android build until recently, so I'm able to report on this bug now.

No crash / force close = good!

No right mouse button events being generated on 2 of the 3 physical devices I've tested:

4.2.2 (Api 17) no mouse event.
6.0.1 (Api 23) mouse event - this is my Cyanogen modded phone if that makes a differece.
7.0 (Api 24) no mouse event.

Left click mouse events and movements come through as normal though.

[AJenbo]

I'm getting reports of some Android 10 users still being affected by this issue (right click not working in the game)

[icculus]

@1bsyl At this point, should we just remove the hack to not let the right mouse button work like pressing Back, since that apparently only affects really old phones...?

[AJenbo]

It's affecting devices all the way up to, and including, Android 10. Which makes up 1/3 of our user base. So I would suggest not removing it, but the current implementation appears to be more then a little broken. I'll try and get my hands on an older device and see what I can come up with.

[icculus]

As far as I know, the current code is there to stop a right mouse click from acting as the "back" button, which apparently it did in extremely old phones that we (probably?) don't support any more. Android earlier than 4.3. Newer releases don't treat right mouse as "back".

[AJenbo]

We have been getting several reports from users, on recent versions of Android, that right click is not working.

There is also several metionings online of this behavior in general.

On Samsung S40 Android 11 there is a mouse option called "Secoundary button" where you can switch between "Open context menu" (right click) and "back". Setting it to back causes right click to not work in SDL applications, and instead trigger dispatchKeyEvent() with a KEYCODE_BACK SOURCE_MOUSE, ACTION_DOWN.

Huawei mediaPad M5 Lite 10 (Android 8.0), and Xiaomi Redmi Note 9 Pro (Android 11) exhibit the same behavior (sending back button events), but does not appear to have any way to adjust this option.

In short this behavior appears to still be the case for many devices, even if this not the behavior of stock Android.

[1bsyl]

not sure where the issue is:
https://github.com/libsdl-org/SDL/blob/main/src/video/android/SDL_androidmouse.c#L207
the code seem to handle all the buttons that comes from.

but there is some callback here "onbackpressed" + some hint:
https://github.com/libsdl-org/SDL/blob/main/android-project/app/src/main/java/org/libsdl/app/SDLActivity.java#L601
do you use that to prevent the app to exit ?

and mouse event can come from various place in the java code...
there can also be "synthetic" event if you use the hint SDL_TOUCH_MOUSE_EVENTS"
https://github.com/libsdl-org/SDL/blob/main/include/SDL_hints.h#L1145

[AJenbo]

We have tried enabling SDL_HINT_ANDROID_TRAP_BACK_BUTTON, but it did not result in the game receiving the SDL_SCANCODE_AC_BACK as documented. Though I should probably point out that it doesn't look like it's shutting down either.

We have not enabled SDL_TOUCH_MOUSE_EVENTS (we support both touch and mouse interface so this would not be desirable).

I'll let you know as soon as I have had a chance to work on this on a local device (probably with in 2 weeks)