1934115 - Geolocation permission gets auto-denied after page load on Rakuten on Android

Status: RESOLVED FIXED

(Firefox for Android :: General, defect)

Description

[Sean Feng [:sefeng211]]

I used a Samsung Galaxy S24 to test this.

STR:

• Open https://pay.rakuten.co.jp/shop/map/?scid=wi_rpay_map_nav_shop on Android
• Execute the following code

navigator.geolocation.watchPosition(function(pos) {
    console.log(pos);
}, function() {console.log("got error")}, {maximumAge: 600000, enableHighAccuracy: true})

Observe the differences between Firefox and Chrome. It gets consistent called in Chrome, but only twice in Firefox.

Comment 1

[Andreas Farre [:farre]]

I wasn't able to reproduce this using GeckoView by doing:

• Run GeckoView in emulator using mach run
• In GeckoView settings make sure Remote Debugging is enabled
• Attach a desktop debugger from about:debugging
• In the connected desktop console, paste and run:

  navigator.geolocation.watchPosition(function(pos) {
      console.log(pos);
  }, function() {console.log("got error")}, {maximumAge: 600000, enableHighAccuracy: true})
  

• Update location in the Android emulator using Extended Controls -> Location -> drop a pin -> Set Location

For every location update I get a log of the console as expected, which is contrary to the results of the report. I was even able to break inside of the success callback of the site's watchPosition callbacks. Sean, the two callbacks that you do get, are they the success case or the fail case?

Comment 2

[Sean Feng [:sefeng211]]

I am still reproducible today, and I got two success cases.

Maybe it requires an real android devices :)

Comment 3

[Andreas Farre [:farre]]

(In reply to Sean Feng [:sefeng] from comment #2)

I am still reproducible today, and I got two success cases.

Maybe it requires an real android devices :)

Yeah so I guess that this is definitely possibility. Were you able to confirm that you updated you position? Because that was the thing that made me get a position update.

Comment 4

[Hsin-Yi Tsai (she/her)[:hsinyi]]

(In reply to Andreas Farre [:farre] from comment #3)

(In reply to Sean Feng [:sefeng] from comment #2)

I am still reproducible today, and I got two success cases.

Maybe it requires an real android devices :)

Yeah so I guess that this is definitely possibility. Were you able to confirm that you updated you position? Because that was the thing that made me get a position update.

NI @sefeng for confirming this.

NI @kagami to see if they can shed some light on this, too.
Thanks!

Comment 5

[Kagami Rosylight 🏳️‍🌈🏳️‍⚧️ [:saschanaz] (they/them)]

The behavior on the website is weird. Even if I permanently allow the geolocation permission it automatically becomes denied.

Comment 6

[Sean Feng [:sefeng211]]

Clearing my NI because we had a discussion about this on Matrix

Comment 7

[Kagami Rosylight 🏳️‍🌈🏳️‍⚧️ [:saschanaz] (they/them)]

So it's weird:
0. (Clear the cookie and site data for this site)

1. Open https://pay.rakuten.co.jp/shop/map/?scid=wi_rpay_map_nav_shop
2. Allow Firefox-level geolocation permission and check "Remember decision for this site"
3. Check the location permission is allowed
4. Reload and wait until the page fully loads
5. Check the permission

Expected: The location permission is still granted
Actual: The permission is now "Blocked" somehow?

Comment 8

[Kagami Rosylight 🏳️‍🌈🏳️‍⚧️ [:saschanaz] (they/them)]

Oops didn't intend to add NI but only cc... We checked nsIPermissionManager and found that somehow the permission becomes permanently denied. Emma thinks this can only happen by browser chrome, in this case probably Fenix. So NI'ing some GeckoView people.

Comment 9

[Emma Zühlcke [:emz]]

(In reply to Kagami Rosylight [:saschanaz] (they/them) from comment #8)

Oops didn't intend to add NI but only cc... We checked nsIPermissionManager and found that somehow the permission becomes permanently denied. Emma thinks this can only happen by browser chrome, in this case probably Fenix. So NI'ing some GeckoView people.

Yes so it's either GeckoView or Fenix code setting that permission. The Permission manager doesn't change permissions unless instructed.

Comment 10

[Makoto Kato [:m_kato]]

I'm not sure, but this issue may be android-component. (I forgot bug number of github or bugzilla).

I guess that Rakuten's Javascript asks the permission twice at same time. But android-component doesn't consider multiple permission requests correctly. Then 1st or 2nd request will be removed by reducer (it is feature name of AC. Reducer merges multiple actions), so eirther is handled by deny.

Also, this site works by GVE since GVE handles multiple permission request as modal. When I test it by GVE, GVE shows permission dialog twice.

Comment 11

[Kagami Rosylight 🏳️‍🌈🏳️‍⚧️ [:saschanaz] (they/them)]

Thanks! android-component is under Fenix: General so I'm moving this there.

Comment 12

[Kagami Rosylight 🏳️‍🌈🏳️‍⚧️ [:saschanaz] (they/them)]

(But I think maybe permission manager can queue the permission request so that each platform implementation doesn't have to deal with it separately. Thoughts?)

Comment 13

[Emma Zühlcke [:emz]]

(In reply to Kagami Rosylight [:saschanaz] (they/them) from comment #12)

(But I think maybe permission manager can queue the permission request so that each platform implementation doesn't have to deal with it separately. Thoughts?)

Potentially? I'm not super familiar with that code. I think it's part of DOM: https://searchfox.org/mozilla-central/search?q=symbol:T_mozilla%3A%3Adom%3A%3AContentPermissionRequestBase&redirect=false
The permission manager does not handle content permission requests directly.

Comment 14

[Kagami Rosylight 🏳️‍🌈🏳️‍⚧️ [:saschanaz] (they/them)]

Hmm yeah, it's nsContentPermissionUtils that immediately pings parent process via PContentPermissionRequest. We can have a DOM side bug for that.

Comment 15

[Olivia Hall [:olivia]]

Does it make a difference in the behavior if enableHighAccuracy is true or false? I think the permissions are slightly different in those situations. Would be curious to know if there is a difference there too for this bug.

Comment 16

[Makoto Kato [:m_kato]]

I think that simple sample is https://codepen.io/mkato/pen/BaxEEzG

ContentStateReducer ignores GeckoResult for 2nd GeoLocation request since URI is same. Ignoring GeckoResult means that it is handled by DENY (due to Java GC).

GVE uses modal dialog for GeoLocation permission, so this issue doesn't occur.

Comment 17

[Makoto Kato [:m_kato]]

(I guess that DOM side might not manage whether current pending request is same URI. Desktop's permission is something modal, so it is unnecessary to care whether current requested permission is same)

Comment 18

[Makoto Kato [:m_kato]]

Attachment: Bug 1934115 - Don't dispose GeckoResult for content permission request. r=#android-reviewers

When duplicated permission request is received, the GeckoResult for the
new request is disposed. It means that it is handled as GeckoResult.DENY.

Even if new permission request for geo location is same, we should merge
both with current prompt then handle all GeckoResult correctly.

Comment 19

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/ba9554db00b5
Don't dispose GeckoResult for content permission request. r=android-reviewers,owlish

Comment 20

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/ba9554db00b5