Open Bug 1728533 Opened 4 years ago Updated 1 year ago

Touch events are offset on specific Samsung devices, in an app using GeckoView

Categories

(GeckoView :: General, defect, P3)

Product:
GeckoView
Component:
General
Version:
Firefox 92
Platform:
Unspecified
All
Type:
defect

Tracking

(Not tracked)

Status:
UNCONFIRMED

People

(Reporter: pc.dieren, Unassigned)

Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.159 Safari/537.36

Steps to reproduce:

Some devices act like they're supposed to, but some devices don't.

Steps to reproduce is to install an app using Geckoview on one of the following devices, using Android 11:

  • Samsung Galaxy A40
  • Samsung Galaxy A50
  • Samsung Galaxy S21 Ultra 5G
  • Samsung Galaxy A71

It's not specific for Samsung devices, because it works okay on the S7 and S9.

Actual results:

When you click in the view of Geckoview, there is a big offset. When you try to click (touch) somewhere, it will click around a centimeter lower, then you are actually touching. So it's not possible for these devices to click on buttons and links in a webpage at all.

Expected results:

It should work normal, like the other devices. If you try to click somewhere, it should click on that spot.

BTW: my Android compile and target version is SDK 30 (Android 11).

I've now also tested it on a Galaxy S20+ with Android 11, but seems to work fine on that device.

So the issue really has something to do with specific devices, but I'm not sure what the difference is of those devices compared to the ones that work perfectly fine. It's not the notch at the top, it's also not the difference between physical or virtual buttons at the bottom.

Component: General → Panning and Zooming
Product: GeckoView → Core

Is the problem affected by either of the following settings in Settings --> Customize:

  • Switching the toolbar position from Bottom to Top (or vice versa)?
  • Unchecking "scroll to hide toolbar"?

Is that a question for me? Because I've only reported this bug for Geckoview and Geckoview doesn't have these options.

(In reply to pc.dieren from comment #4)

Is that a question for me? Because I've only reported this bug for Geckoview and Geckoview doesn't have these options.

My bad, I overlooked that in the bug report. So, new questions:

  • Does the issue occur on the affected devices in the Firefox for Android app?
  • Does your app use the setVerticalClipping() API at all?

My app does not use the setVerticalClipping() API.

I will check if it works on the Firefox for Android app.

It seems that it is not just related to Android 11. Older Android versions on these phones also have these problems.

It also doesn't work properly on a Samsung Galaxy S9+, but it does work on the normal S9.

In the Firefox for Android app everything works normal. The issue only occurs in Geckoview.

I've found out something more.

Besides the touch offset, it also seems like there is a whole area where the touch doesn't respond at all on these devices.

If in portrait mode; the bottom half of the screen doesn't respond at all to touch input.
If in landscape mode; the half of the screen near the buttons don't respond to touch input.

I'm sure the issue has something to do with Geckoview and not with my app layout, because when I use Android's own Webview it works fine.

Issue also reported on a Samsung Galaxy A31 and Samsung Galaxy Note 10+.

(btw: I think the title of this bug should be changed to "Touch offset Samsung", because it doesn't have anything to do with the Android version, but with specific Samsung devices)

Issue also reported on a Samsung Galaxy Tab S6

Summary: Touch offset Android 11 → Touch events are offset on specific Samsung devices, in an app using GeckoView

Thanks for the updates.

Are you able to share an example app that uses GeckoView and experiences the problem?

The reason I asked about Firefox for Android is that it, too, uses GeckoView. So, if it does not experience the problem, and your app does, there may be a difference in how the two use GeckoView that's relevant here.

I have just found out something really important!

The issue occurs if you use Geckoview in combination with ConstraintLayout (androidx.constraintlayout:constraintlayout).

If I use RelativeLayout with Geckoview, everything works fine.
If I use ConstraintLayout with Android's default Webview, everything works fine too.

So it's the combination of Geckoview and ConstraintLayout that will cause the issues.

I've tried multiple versions of ConstraintLayout, but they all gave the same issues.

Thanks for the additional update.

Based on the information so far, this is not looking like an APZ issue:

  • We have ruled out issues related to the dynamic toolbar (comment 6).
  • The issue does not occur in Firefox for Android, and is specific to using GeckoView with ConstraintLayout, which suggests the issue is likely at the GeckoView level.

I'm therefore moving this issue back to the GeckoView component.

Component: Panning and Zooming → General
Product: Core → GeckoView
Summary: Touch events are offset on specific Samsung devices, in an app using GeckoView → Touch events are offset on specific Samsung devices, in an app using GeckoView with ConstraintLayout
Severity: -- → S3
Priority: -- → P3

I have checked with my users, but it seems that most people still have the issues. Only for the test user that helped me with his phone it worked a few times without the ConstraintLayout, but after that the issue returned for him as well. So it has nothing to do with ConstraintLayout.

Updated bug title to remove mention of ConstraintLayout.

My best suggestion for how to make progress with this remains:

(In reply to Botond Ballo [:botond] from comment #12)

Are you able to share an example app that uses GeckoView and experiences the problem?

The reason I asked about Firefox for Android is that it, too, uses GeckoView. So, if it does not experience the problem, and your app does, there may be a difference in how the two use GeckoView that's relevant here.

Summary: Touch events are offset on specific Samsung devices, in an app using GeckoView with ConstraintLayout → Touch events are offset on specific Samsung devices, in an app using GeckoView

I have just sent you the files through email, because I want to keep the files private and don't want to post the files on here.

Thanks. I do not have one of the affected device models but I shared your app privately with Agi, perhaps he or someone else on the GeckoView team does.

One more question, to make sure anyone who tries to reproduce this is testing the right thing: for you, on the affected devices, taps on anything in the app's content (for example, the Login or Register buttons) are affected?

The following issues occur:

  1. In portrait mode the bottom half of the screen isn't responding at touch input at all.
  2. In landscape mode the right side of the screen isn't responding at touch input at all.
  3. If you try to click somewhere at the top (portrait mode) or left (landscape mode) half of the screen, there is an offset.

So if you try to click on the register button in portrait mode, it might click the login button instead, depending on where you click the register button. If you click the login button, nothing will happen, because the click is by the app detected under the button. If you finally are at the login or register page, you're unable to click on the text fields as well. I've managed to login after a long time and the logged in environment has the same issues.

The issue really has something to do with the use of Geckoview in the app, because:

  1. I've used Android's webview before without any issues.
  2. Browsers on android also don't have any issues.

Issue also reported on a Samsung Galaxy S20 FE.

After trying a lot of things, I just figured out something really important!

It seems that the issue only occurs if your package name contains the same word twice. I don't know why it has something to do with this specific issue, but it does.

So the issue will occur if your package name is:
com.test.test
com.test2.test2
com.test3.test3

But everything works fine if the package name is:
com.test
com.test.test2

Hopefully this will help you finding the bug.

Just found out the above only applies to the build.gradle ApplicationID. Not the package name.

I have made a mistake with my conclusion. Some ApplicationID's cause the issue when used with Geckoview, but it's not specifically related to the same word used twice.

To reproduce the issue, it's now really simple; just create a simple Geckoview app with ApplicationID "com.test"
This one won't work correct on all the devices described in my other comments.

Another example:
com.ab as applicationId does work
com.abc as applicationId does not work

The bug is reported 5 months ago, I even bought a phone with this issue to figure out where the bug is coming from.. I've completely figured it out for you guys. Can you please take a look at the issue? So many devices have this issue right now.

It's really simple to reproduce, just create a Geckoview app with an ApplicationID "com.test" or "com.abc" in build.gradle and it doesn't matter which website you're using, they all don't work on all of the devices mentioned above. They all have these touch issues.

Flags: needinfo?(etoop)
Flags: needinfo?(etoop)
Priority: P3 → --

Can you take a quick look at this Jonathan?

Flags: needinfo?(jonalmeida942)

I tried to reproduce this with the instructions above by changing GVE to those package names, but to no avail. What I noticed in the code sent over is that in the RelativeLayout, the child GeckoView has a layout_height of "wrap_content", which may affect touch gestures.

Not being able to reproduce the issue, I'm more inclined to suspect it's because of how the layouts are setup. In GVE, we're also using the NestedGeckoView, so that might be another thing worth trying out to see if it helps in your app.

Flags: needinfo?(jonalmeida942)
Priority: -- → P3

Did you test on one of the devices I described? What device did you test it on?

Even when I use other form of layouts, they all give the same issue.

Also when I create the most basic sample app with only the required parts from the GeckoView Wiki instruction (so only the code from the blocks at https://wiki.mozilla.org/Mobile/GeckoView and nothing more than that), this issue applies if I use these names.

Flags: needinfo?(jonalmeida942)

I've just copied the whole GeckoView Example with the NestedGeckoView from the link you provided (https://searchfox.org/mozilla-central/source/mobile/android/geckoview_example), but the same issue occurs.

If I keep all the files the way it's in that link, with the name "org.mozilla.geckoview_example", it works all fine, but as soon as I only changed the applicationId, PackageId and folder names to "com.test.test" the touch issue is back.

BTW: the toolbar at the bottom of that example app works fine, so it's not the whole app that's having issues, but only the view that's loading the page.

(In reply to pc.dieren from comment #27)

Did you test on one of the devices I described? What device did you test it on?

Even when I use other form of layouts, they all give the same issue.

Also when I create the most basic sample app with only the required parts from the GeckoView Wiki instruction (so only the code from the blocks at https://wiki.mozilla.org/Mobile/GeckoView and nothing more than that), this issue applies if I use these names.

Unfortunately, I also do not have access to those devices.

Is there a reason your package name needs to be one of those that you found? Typically, changing the app ID is enough for app publishing or uniqueness.

The problem could either be:

  • com.test.test and others are some privileged package name on (specific?) Samsung devices. If this was true though, it wouldn't just be GV affected.
  • There is some error taking place when converting the app ID and package names over.
Flags: needinfo?(jonalmeida942)

I have an already existing app in the Play Store, that has an ID which has the issue.

I can't change it, because that would require me to publish a completely new app to the Play Store, because everything is all bound to your app ID.

If I change the app ID, I can't publish an update anymore and I don't want to publish my app as a completely new one, because my users would have to delete the old app and download the new one.

Issue still exists in Geckoview-beta 125.0.20240318085508

You need to log in before you can comment on or make changes to this bug.