Closed Bug 1596164 Opened 5 years ago Closed 2 years ago

navigator.geolocation.getCurrentPosition success callback not called when maximumAge option is specified

Categories

(GeckoView :: General, defect, P2)

70 Branch
Unspecified
Android
defect

Tracking

(Webcompat Priority:revisit, firefox101 wontfix, firefox102 wontfix, firefox103 fixed)

RESOLVED FIXED
103 Branch
Webcompat Priority revisit
Tracking Status
firefox101 --- wontfix
firefox102 --- wontfix
firefox103 --- fixed

People

(Reporter: ksenia, Assigned: m_kato)

References

()

Details

(Whiteboard: [geckoview:p2] [geckoview:2022h2?] )

Attachments

(1 file)

As reported here https://github.com/webcompat/web-bugs/issues/43954

STR:

  1. Visit https://www.playnow.com/login/ in Firefox Fenix/ Fenix Nightly
  2. Enter login and password (can be anything)
  3. Click "Log in now" button
  4. Click "Allow" in the geolocation permission prompt

Expected behavior:
Form submit is happening and error message displayed: "Sorry, your login information did not match our records..."
Actual:
Form submit is not performed and submit button becomes disabled

A reduced test case:
https://codepen.io/ksy36/pen/NWWOKgJ

This seems to be caused by maximumAge specified in the options (maximumAge: 10000). If I remove it, the success callback is fired.

I get expected behavior in Firefox for Android, but not in Fenix Preview. Is this a GeckoView bug?

Flags: needinfo?(snorp)

Seems like it. Adding to triage.

Flags: needinfo?(snorp)
Whiteboard: [geckoview]

The priority flag is not set for this bug.
:garvan, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(gkeeley)
Flags: needinfo?(gkeeley)
Priority: -- → P2
Component: DOM: Geolocation → General
Product: Core → GeckoView
Whiteboard: [geckoview] → [geckoview:p2]
Rank: 15
Webcompat Priority: ? → revisit

Since we're fixing some other geolocation bugs, we should retest this bug.

Whiteboard: [geckoview:p2] → [geckoview:p2] [geckoview:2022h2?]

When reporting current location by here, doesn't SendLocation send it?

Actually, GV uses that nsGeoPosition's timestamp is older than PR_Now(). But other platform uses PR_Now() now, so can we fix it by using same way?

android.location.Location.getTime() will return the acquired location time
that depends on location service. But maximumAge will be calculated by
current time (PR_Now()). So if the acquired time is old time,
nsGeolocationRequest::SendLocation won't send the location due to too old
(isTooOld=true in nsGeolocationRequest::SendLocation).

Like other platforms, we should pass PR_Now as the location time instead.

Also, GVE sometimes hits debug assertion since heading and/or speed aren't
expected value, so this patch fixes this situation.

Assignee: nobody → m_kato
Status: NEW → ASSIGNED
Pushed by m_kato@ga2.so-net.ne.jp: https://hg.mozilla.org/integration/autoland/rev/295e95d1ce00 Use PR_Now instead of location service's acquired time. r=geckoview-reviewers,agi
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 103 Branch

This is an old bug, so there's no rush to uplift this fix to Beta 102. The fix can ride the trains with 103.

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

Attachment

General

Created:
Updated:
Size: