1492408 - Firefox freezes on infinite JS loop touching history

Status: RESOLVED FIXED

(Core :: DOM: Navigation, defect, P2)

Description

[luca.defeo]

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.

Comment 1

[Kanchan Kumari QA]

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.

Comment 2

[Darkspirit]

Why don't browsers implement rate limiting for such Javascript APIs?

Comment 3

[Andrew Overholt [:overholt]]

The slow script dialogue is expected but the crash is not.

We should try to catch the crash in a debugger.

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

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.

Comment 5

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

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

[Olli Pettay [:smaug][[e-mail]]]

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.

Comment 7

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to Olli Pettay [:smaug][[e-mail]] 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

[BugBot [:suhaib / :marco/ :calixte]]

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

[Andrew McCreight [:mccr8]]

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

[:Gijs (out for now; he/him)]

(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.