Firefox freezes on infinite JS loop touching history
Categories
(Core :: DOM: Navigation, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox64 | --- | wontfix |
People
(Reporter: luca.defeo, Assigned: pbz)
References
(Blocks 1 open bug)
Details
(Keywords: csectype-dos)
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0 Build ID: 20180810121301 Steps to reproduce: Executed this code for(let i=0;i<1/0;++) document.location.href="#",window.history.back(),window.history.forward(); Actual results: Firefox quickly froze, impossible to kill tab, impossible to switch virtual console in Linux. Had to power down the machine. Expected results: Firefox should have proposed to kill the tab.
Updated•6 years ago
|
Comment 1•6 years ago
|
||
I could reproduce this issue on User Agent Mozilla/5.0 (X11; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0 Executing the code made Firefox unresponsive and it gives slow script warning. After a couple of minutes Firefox crashed. https://crash-stats.mozilla.com/report/index/5699cb51-3f21-4c37-8eb4-1b7880180924 Though Crash report indicates to APZ bug I am placing this under Core:Java Script engine as per this bug report. Feel free to place this under more appropriate component.
Updated•6 years ago
|
Comment 2•6 years ago
|
||
Why don't browsers implement rate limiting for such Javascript APIs?
Updated•6 years ago
|
Comment 3•6 years ago
|
||
The slow script dialogue is expected but the crash is not. We should try to catch the crash in a debugger.
Updated•5 years ago
|
Comment 4•1 year ago
|
||
In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.
Isn't this fixed by bug 1708150? Now these APIs require user activation. Or do you still need to limit the rate of these APIs like bug 1720926?
Comment 6•1 year ago
|
||
User activation isn't enabled. It needs still some more work.
And it wouldn't affect how web exposed APIs work.
But I'd expect the behavior to be somewhat different these days when history.back()/forward() are asynchronous.
(In reply to Olli Pettay [:smaug][bugs@pettay.fi] from comment #6)
User activation isn't enabled. It needs still some more work.
And it wouldn't affect how web exposed APIs work.
Oh? I'll try to fix my misunderstanding later...
But I'd expect the behavior to be somewhat different these days when history.back()/forward() are asynchronous.
Well, I cannot reproduce this bug in data URI nor JSFiddle. Could be not reproducible with the reported testcase anymore?
luca.defeo: Do you still see this bug in your environment?
Comment 8•1 year ago
|
||
Redirect a needinfo that is pending on an inactive user to the triage owner.
:farre, since the bug has recent activity, could you have a look please?
For more information, please visit auto_nag documentation.
Comment 9•1 year ago
|
||
I'll put this as WORKSFORME based on comment 7. If somebody else can reproduce this issue, feel free to reopen or comment in this bug.
Comment 10•1 year ago
|
||
(In reply to Andrew McCreight [:mccr8] from comment #9)
I'll put this as WORKSFORME based on comment 7. If somebody else can reproduce this issue, feel free to reopen or comment in this bug.
bug 1314912 added rate limits for the history + location APIs which presumably fixed this.
Description
•