Add block area to prevent accidental touch on edge

[DeltaFlyerW]

Description

Add an anti-accidental touch feature, which allow user to select some area on screen that the touch inside will not be a valid input event for game.

Justification

As screen-to-body ratio grows in decent mobile devices, accidental touch has been a problem for many play styles. During play, accidental touch causes unexpected drop as your palm or finger touch screen edge.

[Rian8337]

I've tidied up some stuff in the code and added a timeout for the "Changes Saved!" text so that it will not stay like that throughout the whole lifecycle, but there remain a few behaviors that must be addressed.

[Rian8337]

The core logic of the block area now works as intended in custom playfield sizes. However, after more intensive testing, I think the UI of the block area manager can still use a bunch of work. There are weird irks that may hinder UX:

• This can be considered a niche problem since I doubt anyone would block this part of the window from input, but a block area can overlap buttons, making them impossible to press. This can easily be solved applying a z-index to the button container, but this will produce a case where a block area can be completely behind a button, so you cannot interact with it at all. Maybe a more viable approach is to put the buttons on the left/right side with a grid container?
• Maybe a block area should have a minimum width and height? It is quite tricky to manage very small areas, and I doubt many players will try to hyper-optimize blocking small areas.
• Buttons still press if you press on them and drag away (usually this movement is done in touchscreen to indicate cancellation). A way to fix this is to listen to mousemove or touchmove and cancel the operation on mouseup or touchend if it fires. If it is not enough, the operation may be cancelled if there is enough displacement from the press position to the movement position (see how BeatmapButton handles this).
• Is there a specific reason for a347d04? It is not guaranteed that the WebView loads instantly in slow devices. In such cases, showing a loading indicator is more user-friendly than having them stare at a blank screen.

Despite the above, I received an information from @Reco1I that he may try to make a native Android UI for this rather than using a WebView, but I would like to confirm with you if you are okay with it.

Additionally, here is a video demonstrating the issues:

2024-05-09.20-43-59.mp4

Resolved

[Reco1I]

My man concern about this is that usign HTML and a WebView doesn't look like a good choice, infact you can do the same with Android native framework and it will be more compatible since contents/dimensions inside the WebView does not respect the app theme.

See https://developer.android.com/guide/topics/resources/style-resource

[Reco1I]

As Rian says I would offer myself to contribute.

[DeltaFlyerW]

• Maybe a block area should have a minimum width and height? It is quite tricky to manage very small areas, and I doubt many players will try to hyper-optimize blocking small areas.

the current implementation does enforce a minimum dimension of 5px for both width and height. This can be observed in the video at the 00:26 mark, as detailed

osu-droid/assets/html/blockAreaSetting.html

Lines 317 to 320 in 86afc14

	//Limit minimum width and height
	if (width < 5) width = 5;
	if (height < 5) height = 5;

---

• Is there a specific reason for a347d04? It is not guaranteed that the WebView loads instantly in slow devices. In such cases, showing a loading indicator is more user-friendly than having them stare at a blank screen.

An issue occurs that re-entering the configuration page was causing the loading animation to persist indefinitely.

---

Despite the above, I received an information from @Reco1I that he may try to make a native Android UI for this rather than using a WebView, but I would like to confirm with you if you are okay with it.

I would be glad to have a contributor take part in this feature. Should @Reco1I decide to proceed with creating a native Android UI rather than using a WebView, I will hold off on making further commits to this PR. If any assistance is needed, please do not hesitate to reach out—I am willing to help in any way I can.

[Rian8337]

the current implementation does enforce a minimum dimension of 5px for both width and height

Aha. It was noticeable that the red squares don't perfectly align when the block area was made as small as possible, although I'm not sure if it's enough to not confuse the user on which corner was pressed. The CSS does have a cursor property for each corner, but this is irrelevant due to touchscreen.

Nonetheless, there's no need to work on the current UI for now. The core logic can be reused by the Android native UI if it's made.

[Rian8337]

As an update, @Reco1I will attempt to implement this in a superseding PR. Until that PR is opened, this PR can remain open.