2034120 - Rejecting to enable system permission does not stop the browser to show system permission on a second attempt

Status: VERIFIED FIXED

(Toolkit :: Geolocation Provider, defect)

Description

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

1. Open maps.google.com
2. Grant browser geolocation permission, and fill the remember checkbox
3. Click the locator button to trigger geolocation request
4. Close the resulting system prompt
5. Restart step 1 (you need to reload the page, otherwise the locator button will remain disabled)

Expected: The second attempt to do step 3 should not trigger system prompt
Actual: The system prompt always happens, regardless of whether the user rejected it or not.

Chrome only shows it once and does not show it again on any further attempt.

The extreme version of this repro is this:

setInterval(() => navigator.geolocation.getCurrentPosition(console.log, console.error), 1000);

This triggers infinite loop of opening system prompt. Which is not too harmful as we show an in-browser popup to trigger system prompt (i.e. each system prompt opens only on a user interaction), but is frustrating enough.

Comment 1

[BugBot [:suhaib / :marco]]

:handyman, since you are the author of the regressor, bug 2018365, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 2

[David Parks [:handyman]]

(Continued from off-line discussion.)

Geolocation determines whether or not to show the doorhanger by consulting ContentPermissionRequestBase::RequestDelayedTask, which proceeds through RequestPromptEvent -> nsContentPermissionUtils::AskPermission -> ContentParent::RecvPContentPermissionContructor -> ... yadda yadda yadda ... -> nsContentPermissionRequestProxy::Init -> ContentPermissionPrompt::prompt -> PermissionPrompt::prompt -> SitePermissions::getForPrincipal -> PermissionManager::GetPermissionObject. If the PermissionManager was sensitive the system setting then this would presumably fix this issue (by presenting the door-hanger, which can be permanently dismissed, instead of system preferences, which can only be blocked by an internal config pref). Bug 2022043 did the work to make the user-visible state reported by PermissionManager to be system-preference-sensitive, but my theory is it has a blind spot in this case, but I haven't confirmed that yet.

Comment 3

[BugBot [:suhaib / :marco]]

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

Comment 4

[David Parks [:handyman]]

This will be difficult to resolve because ContentPermissionPrompt is basically entirely sync calls but fetching permission status from the OS is async. IOW, Permissions::Query uses PermissionStatus, which is async. Watching for the permission early (like startup) is possible but not great. For a great majority users, geolocation permission won't be relevant, so that' s all wasted.

Comment 5

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

But it's the matter of not calling SendRequestGeolocationPermissionFromUser, right? https://searchfox.org/firefox-main/rev/986b2e474acca54ab469aca8d549b71cdcea33a5/dom/geolocation/Geolocation.cpp#386-424

If we already tried opening prompt, then SystemGeolocationPermissionBehavior should become noprompt.

Comment 6

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

Attachment: WIP: Bug 2034120 - Open system permission prompt only once per each Firefox session r=handyman

Comment 7

[David Parks [:handyman]]

Attachment: Bug 2034120: Tell content permissions to ignore an ALLOW SitePermission if geolocation is not available r=saschanaz!

Geolocation isn't available if we require the OS to provide it but it
doesn't have permission to.

Comment 8

[BugBot [:suhaib / :marco]]

The bug is marked as tracked for firefox151 (beta). However, the bug still isn't assigned.

:jstutte, could you please find an assignee for this tracked bug? Given that it is a regression and we know the cause, we could also simply backout the regressor. If you disagree with the tracking decision, please talk with the release managers.

For more information, please visit BugBot documentation.

Comment 9

[David Parks [:handyman]]

Attachment: Bug 2034120: [beta] Tell content permissions to ignore an ALLOW SitePermission if geolocation is not available r=saschanaz!

Geolocation isn't available if we require the OS to provide it but it
doesn't have permission to.

Comment 10

[David Parks [:handyman]]

Attachment: Bug 2034120: [release] Tell content permissions to ignore an ALLOW SitePermission if geolocation is not available r=saschanaz!

Geolocation isn't available if we require the OS to provide it but it
doesn't have permission to.

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/6102d967f68b
https://hg.mozilla.org/integration/autoland/rev/51e15cc1dc27
Tell content permissions to ignore an ALLOW SitePermission if geolocation is not available r=saschanaz

Comment 12

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/51e15cc1dc27

Comment 13

[Donal Meehan [:dmeehan]]

:handyman, could you add uplift request forms to the uplifts?
https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift#Submit_the_Uplift_Request_Form

Comment 14

[David Parks [:handyman]]

Comment on attachment 9573610 [details]
Bug 2034120: [beta] Tell content permissions to ignore an ALLOW SitePermission if geolocation is not available r=saschanaz!

Beta/Release Uplift Approval Request

• User impact if declined/Reason for urgency: Missing geolocation door hanger when site permissions are set to allow.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: 1. Disable Windows location services

2. Go to a page that requests location (e.g. browserleaks.com/geo)
3. Permanently allow location in door hanger.
4. Press Cancel in dialog that appears
5. Reload the page

Expected: doorhanger
Actual: no door hanger

• List of other uplifts needed: None
• Risk to taking this patch: Medium
• Why is the change risky/not risky? (and alternatives if risky): The code is fairly straightforward but has no maintainer and hasn't been stress tested.
• String changes made/needed: N/A
• Is Android affected?: No

Comment 15

[David Parks [:handyman]]

Comment on attachment 9573611 [details]
Bug 2034120: [release] Tell content permissions to ignore an ALLOW SitePermission if geolocation is not available r=saschanaz!

Beta/Release Uplift Approval Request

• User impact if declined/Reason for urgency: Missing geolocation door hanger when site permissions are set to allow.

• Is this code covered by automated tests?: No

• Has the fix been verified in Nightly?: No

• Needs manual test from QE?: Yes

• If yes, steps to reproduce: 1. Disable Windows location services

  Go to a page that requests location (e.g. browserleaks.com/geo)
  Permanently allow location in door hanger.
  Press Cancel in dialog that appears
  Reload the page

Expected: doorhanger
Actual: no door hanger

• List of other uplifts needed: None
• Risk to taking this patch: Medium
• Why is the change risky/not risky? (and alternatives if risky): The code is fairly straightforward but has no maintainer and hasn't been stress tested.
• String changes made/needed: N/A
• Is Android affected?: No

Comment 16

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/40be00cf769b
https://hg.mozilla.org/releases/mozilla-beta/rev/622c1c96009c

Comment 17

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/a6ff0c7939ff
https://hg.mozilla.org/releases/mozilla-release/rev/c6d0672db9a5

Comment 18

[Alin Ilea, Desktop Test Engineering]

Verified - Fixed in 150.0.1 (build id: 20260427013024) Beta 151.0b3 and Nightly 152.0a1(2026-04-28).