Requesting geolocation before previous request has been handled interferes with accepting previous request
Categories
(Core :: DOM: Geolocation, defect)
Tracking
()
People
(Reporter: j031mckay, Unassigned)
Details
(Keywords: testcase-wanted)
User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:99.0) Gecko/20210101 Firefox/99.0
Firefox for Android
Steps to reproduce:
Clicked the GPS access request popup for my https:// LAN site
Actual results:
Required clicking the green underlined link "Learn more..." before it allowed to check the "Remember this decision" box and click "Allow Location access" button
(May also require disabling ignore requests checkbox in privacy GPS settings)
Expected results:
Should check when checked, and accept when the accept button is pressed.
This occurred on both the Linux Desktop and Android browser versions.
This glitch was recently seen in the 103.0 (64-bit) Ubuntu package
Comment 2•3 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Widget: Win32' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
Comment 3•3 years ago
|
||
Presumably Bugbug was going off the User-Agent string when assigning this to Widget::Win32. Redirecting to a more plausible component.
Comment 4•3 years ago
|
||
As a GPS device is also involved, moving this to Core > DOM: Geolocation.
Comment 5•3 years ago
|
||
Works for me on Wayland on Ubuntu.
Reporter, what Linux system did you see this on? Which config of X11, XWayland, or native Wayland?
I was able to ascertain the underlying cause was some badly written recursive JavaScript re-popping a GPS access prompt before the user can OK the accept always checkbox. On pre v103 browsers this was a blocking call (tested on v91) where a single prompt would need dismissed before successive dialogs could appear, but due to other user needs this may have changed behavior ( May be related https://stackoverflow.com/questions/3397585/navigator-geolocation-getcurrentposition-sometimes-works-sometimes-doesnt#3885172 ).
The website maintainer already fixed the JavaScript to ensure a single prompt to workaround the issue. Unfortunately the busy dialog issue still seems to arise on newer X11/Gnome desktops, mobile/android, and iPhones.
I did run the inspect console to see if any useful information could help, but no clues on that front.
Thanks again for looking at the edge case. =)
Comment 7•3 years ago
|
||
Thanks. Trying to resummarize. Still unconfirmed and needs a test case.
Description
•