Geolocation watchPosition is able to flood alerts
Categories
(Firefox for Android Graveyard :: General, defect)
Tracking
(Not tracked)
People
(Reporter: brad, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: crash, csectype-dos, testcase)
Crash Data
Attachments
(1 file)
|
(deleted),
text/html
|
Details |
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:74.0) Gecko/20100101 Firefox/74.0
Steps to reproduce:
Call navigator.geolocation.watchPosition() with an error function that alerts the user and the option to timeout after a short period of time (250ms, in my case). A minimum page to reproduce this is pasted below. I had to run a webserver to open this on my phone.
<html>
<script>
navigator.geolocation.watchPosition(
function(){},
function() {
alert("error");
},
{"timeout": 250}
);
</script>
</html>
Actual results:
The client is flooded with alerts at a speed where clicking "Prevent this page from making additional dialogs" and the "Ok" button are not possible. This forces the user to completely exit the application or the browser will crash.
Expected results:
I expected one alert to appear at a time, or for Firefox to have prevented this in some way.
|
Reporter | |
Comment 1•5 years ago
|
||
I'd like to add that, after the user closes the app or it crashes, the page will try to load on the next start. If it succeeds or is cached, then the script will run again and this will repeat until the user manages to close the page, which was not an easy task for me. I didn't catch this the first time because where I initially ran into the problem, the watchPosition call was behind a button, and I only ran the test page once.
(In reply to Brad Alfirevic from comment #0)
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:74.0) Gecko/20100101 Firefox/74.0
Steps to reproduce:
Call navigator.geolocation.watchPosition() with an error function that alerts the user and the option to timeout after a short period of time (250ms, in my case). A minimum page to reproduce this is pasted below. I had to run a webserver to open this on my phone.
<html>
<script>
navigator.geolocation.watchPosition(
function(){},
function() {
alert("error");
},
{"timeout": 250}
);
</script>
</html>Actual results:
The client is flooded with alerts at a speed where clicking "Prevent this page from making additional dialogs" and the "Ok" button are not possible. This forces the user to completely exit the application or the browser will crash.
Expected results:
I expected one alert to appear at a time, or for Firefox to have prevented this in some way.
|
|
Reporter | |
Comment 2•5 years ago
|
||
Sorry to triple post, but tested it on desktop again (Firefox 74.0) and it seems that the alerts do indeed pile up and the tab is frozen. Just want to give information that may be helpful. I don't know if I should change the product or what, so I'll leave it up to you fine folk.
(In reply to Brad Alfirevic from comment #1)
I'd like to add that, after the user closes the app or it crashes, the page will try to load on the next start. If it succeeds or is cached, then the script will run again and this will repeat until the user manages to close the page, which was not an easy task for me. I didn't catch this the first time because where I initially ran into the problem, the watchPosition call was behind a button, and I only ran the test page once.
(In reply to Brad Alfirevic from comment #0)
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:74.0) Gecko/20100101 Firefox/74.0
Steps to reproduce:
Call navigator.geolocation.watchPosition() with an error function that alerts the user and the option to timeout after a short period of time (250ms, in my case). A minimum page to reproduce this is pasted below. I had to run a webserver to open this on my phone.
<html>
<script>
navigator.geolocation.watchPosition(
function(){},
function() {
alert("error");
},
{"timeout": 250}
);
</script>
</html>Actual results:
The client is flooded with alerts at a speed where clicking "Prevent this page from making additional dialogs" and the "Ok" button are not possible. This forces the user to completely exit the application or the browser will crash.
Expected results:
I expected one alert to appear at a time, or for Firefox to have prevented this in some way.
|
||
Comment 3•5 years ago
|
||
Dan, Johann, do we consider this a security or DOM bug?
|
||
Comment 4•5 years ago
|
||
|
|
||
Comment 5•5 years ago
|
||
It's a denial of service, and definitely not very nice on Fennec (if you've granted the site Geolocation perms). This doesn't need to be treated as a security bug, but the Android version needs to deal with it for sure. There's still something wrong on Desktop but I didn't have any severe problems -- could easily close the tab.
Because there are problems on both desktop and fennec part of the problem is in the geolocation code I think. But the overwhelm and crash is an issue for the Fennec front end to solve (see crash signature).
On Fennec:
- no problem if I deny geolocation permission. One "error" alert and done.
- overwhelm and crash if I allow geolocation. bp-e0e70d40-2763-45a7-91ab-bfba70200430
TIP: do not "remember" your decision! if you do then the browser restarts back into the broken tab -- not sure how to get out of it. If you don't remember the permission you have a chance to escape when it asks you to grant it again.- alert() is supposed to be tab-modal -- stopping scripts until it's dismissed. These just pile up.
- After a while I see the "this page is doing a lot of alerts, do you want to stop?" checkbox, but I can't check the box and hit OK before the next one overwrites it.
Fenix:
- basically the same as Fennec, but slower.
- I click "send report to mozilla" but my crash doesn't show up in about:crashes. I couldn't find my crash on crash-stats either. Don't know if it wasn't sent or if it's just too big a haystack. Tried to search the URL field for the testcase but almost none of the Fenix crashes capture the current URL (something like 3 URLs out of 2000 crashes in the last 30 minutes)
- because Fenix restarts into the home page / tab list thing it's easier to recover (close the offending page) than Fennec -- you don't get re-launched into the same hellish problem.
- If there's not something known broken with the Fenix crash reporter, then this is a case that breaks it.
On Desktop:
- If I grant the geo permission I get one polite alert at a time.
- too much recursion error messages keep being sent to the console though (check counter, repeat messages are de-duped)
- eventually I get the version of the alert with the checkbox to stop the page from asking. Checking that appears to do nothing
- If I keep clicking OK I get a mix of dialogs with and without the checkbox to stop the page from alerting again.
- If I've checked the box, eventually the dialogs do stop (long after I should have given up) and I get the page back
- I'm never really stuck though -- it's easy to simply close the tab and move on.
The Fennec and Fenix crashes could be completely different -- I can't tell what the Fenix one is because of the crash reporter problems.
The desktop behavior seems to be acceptable so I don't think this is a geolocation/DOM bug.
|
||
Comment 6•5 years ago
|
||
Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is -- (Backlog,) indicating it has has not been previously triaged, the bug's Severity is being updated to -- (default, untriaged.)
|
|
||
Updated•5 years ago
|
|
|
||
Comment 7•5 years ago
|
||
I marked this as WONTFIX - if someone has a strong opinion about fixing this in Fennc, please re-open.
|
||
Comment 8•4 years ago
|
||
It seems like people are frequently hitting this in release Fennec and based on Dan's analysis it looks like Fenix will have the same problem, is this really a WONTFIX or should we at least track the bug (with a lower priority) for Fenix/GV?
|
|
||
Comment 9•4 years ago
|
||
We won't fix this for Fennec, but I did file a Fenix bug for this https://github.com/mozilla-mobile/fenix/issues/11469
|
Assignee | |
Updated•4 years ago
|
Description
•