Closed Bug 1772125 Opened 3 years ago Closed 3 years ago

GeoClue back-end confusingly denies permission requests if system location services are off

Categories

(Core :: DOM: Geolocation, defect)

Unspecified
Linux
defect

Tracking

()

VERIFIED FIXED
103 Branch
Tracking Status
firefox-esr91 --- unaffected
firefox101 --- unaffected
firefox102 + verified
firefox103 + verified

People

(Reporter: emilio, Assigned: emilio)

References

(Regression)

Details

(Keywords: regression)

Attachments

(1 file)

On my machine, going to https://wikishootme.toolforge.org/ and clicking "Allow" on the prompt shows "User denied the request for Geolocation.".

Bisecting it it points to bug 1769664. It might be a local issue (user not in the right group or something? need to dig), but still we should fall back to MLS rather than throwing a permission denied error around.

[Tracking Requested - why for this release]: Functionality regression on Linux, at least on some configurations.

[Parent 108088: Main Thread]: E/GeoclueLocation Failed to start client: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Geolocation disabled for UID 1000

Does running /usr/lib/geoclue-2.0/demos/where-am-i or /usr/libexec/geoclue-2.0/demos/where-am-i show the location correctly on your system?

If not then you most likely don't have a Geoclue authorization agent running.

If the above do work then you might be hitting an issue present in some older Geoclue versions (before 2.6.0; I think only 2.5.[6-7] are affected) - if that's the case then the second geolocation request should work normally (only the very first after the Firefox startup will be denied).

Geolocation disabled for UID 1000

Check also system settings if geolocation isn't explicitly disabled there.

https://help.gnome.org/users/gnome-help/stable/privacy-location.html.en

Even tho it is a configuration error, it is extremely confusing to click
"Allow" in Firefox and get a "denied access" error.

Instead fall back to MLS once we error, like other location providers
do.

Assignee: nobody → emilio
Status: NEW → ASSIGNED

Right, so I agree this is a configuration error on my side, but still seems like we should do better. On other platforms when the system provider fails we fall back to MLS (in fact we race with it).

Instead of that I opted to immediately fallback to MLS on error in comment 5, which is easier to reason about, IMHO, but lmk if you disagree :)

Yeah, I had location services off in the gnome settings, which explains this.

Summary: GeoClue back-end denies permission requests that used to work. → GeoClue back-end confusingly denies permission requests if system location services are off

I get your point that, for example, Windows Location provider also falls back to MLS if a user has geolocation services disabled system-wide.

Can I play with this issue and the proposed patch this weekend or is it more urgent?
I especially want to see what happens on transient errors, whether the reported location will make wild jumps between the Geoclue-provided and the MLS-provided position.

It's fine, we're early in the beta cycle. As long as we get this fixed on beta on time, seems fine to me. I appreciate your careful review :)

The Bugbug bot thinks this bug is a defect, but please change it back in case of error.

Type: enhancement → defect
Has Regression Range: --- → yes

Set release status flags based on info from the regressing bug 1769664

Pushed by emilio@crisal.io: https://hg.mozilla.org/integration/autoland/rev/533ad0ead234 Implement MLS fallback for GeoclueLocationProvider. r=maciejsszmigiero
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 103 Branch

Can we get this uplifted to beta as this is a 102 feature? Thanks

Flags: needinfo?(emilio)

Comment on attachment 9279095 [details]
Bug 1772125 - Implement MLS fallback for GeoclueLocationProvider. r=maciejsszmigiero

Beta/Release Uplift Approval Request

  • User impact if declined: Linux geolocation fails if location services are disabled at the OS level.
  • Is this code covered by automated tests?: Yes
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: Yes
  • If yes, steps to reproduce: comment 0 for example
  • List of other uplifts needed: none
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Relatively straight-forward fallback code for this new feature to keep using MLS if disabled.
  • String changes made/needed: none
  • Is Android affected?: No
Flags: needinfo?(emilio)
Attachment #9279095 - Flags: approval-mozilla-beta?
Flags: qe-verify+

Comment on attachment 9279095 [details]
Bug 1772125 - Implement MLS fallback for GeoclueLocationProvider. r=maciejsszmigiero

Approved for 102 beta 5, thanks.

Attachment #9279095 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
QA Whiteboard: [qa-triaged]

I was not able to reproduce the issue on Ubuntu 20.4 using build 102.0a1(20220512094957). I have the location settings off and while loading site https://wikishootme.toolforge.org/ I get two prompts and after click on "Allow" for both I get the map. Am I using the correct build and OS in order to reproduce it? Thank you.

Flags: needinfo?(emilio)

What do you you see in the terminal if you run with MOZ_LOG=GeoclueLocation:5? Most likely you don't have Geoclue installed or something? Not sure, I don't use Ubuntu myself.

Flags: needinfo?(emilio)

It's probably better to try reproducing this issue on Fedora, since Ubuntu may have a different shell and shell-related plumbing.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #19)

What do you you see in the terminal if you run with MOZ_LOG=GeoclueLocation:5? Most likely you don't have Geoclue installed or something? Not sure, I don't use Ubuntu myself.

I do not get anything. I have installed Geoclue but still nothing displayed if running the command.

I was able to reproduce the issue on Fedora Linux 36 using build 102.0b1(20220530132252) after first 'Allow', I get "User denied the request for Geolocation.".
Verified as fixed on Fedora Linux 36 using build 102.0b5(20220607212916) and Nightly 103.0a1(20220608214824).

Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: