1928670 - Whole browser hangs on infinite javascript loop in one of the browser tabs

Status: NEW

(DevTools :: General, defect, P2)

Description

[[:Ash]]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0.0.0 Safari/537.36

Steps to reproduce:

I ran a simple test :
Open firefox console, run an simple infinite while loop in javascript as below :

while(true) {
console.log("test");
}

Actual results:

It started slowing down the browser, switching tabs was painfully slow and eventually the whole browser became unresponsive. I even tried in safe mode with all my extensions disabled just to make sure it's not due to one of the extensions.

Expected results:

Isolate the memory intensive tab and not affect/freeze the whole browser (like what happened when the test on a chromium based browser)

Comment 1

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

The Bugbug bot thinks this bug should belong to the 'Firefox::Tabbed Browser' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Negritas Sergiu, Desktop QA]

Hello! Thank you for submitting this issue I have tried to reproduce the issue on my end but unfortunately I wasn't able to with firefox 134.0a1(2024-11-06) on MacOS 15.
Could you please answer the following questions in order to further investigate this issue?

1. Does this issue happen with a new profile? Here is a link on how to create one: https://support.mozilla.org/en-US/kb/profile-manager-create-remove-switch-firefox-profiles
2. Does this issue happen in the latest nightly? Here is a link from where you can download it: https://www.mozilla.org/en-US/firefox/channel/desktop/
3. Do you have any addons installed? If yes could you please list them?

Comment 3

[[:Ash]]

Attachment: Issue screen recording on firefox nightly

Screen recording of the issue on firefox nightly 134.0a1 (2024-11-06) (aarch64)

Comment 4

[[:Ash]]

1. Yes, I tried making a new profile and could reproduce using the same steps.
2. Yes, Downloaded latest nightly and tested the same. (Attached a screen recording)
3. With a new profile, I don't have any addons installed and also mentioned previously that I tried to check in firefox safe-mode as well. I could replicate.

Comment 5

[[:Ash]]

Same was also reproducible on a windows machine as reported in the reddit thread :
https://www.reddit.com/r/firefox/comments/1ggw40z/firefox_hangs_on_infinite_javascript_loop_in_one/

Comment 6

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

The severity field is not set for this bug.
:dwalker, could you have a look please?

For more information, please visit BugBot documentation.

Comment 7

[Mayank Bansal]

Profile: https://share.firefox.dev/3CQ1ER6 . I get rapid memory increase and a "this tab is slowing your browser" warning.
On Chrome, I see rapid memory increase, but the UI is relatively smooth.

Comment 8

[Alexandre Poirot [:ochameau]]

Were you able to reproduce a frozen or slow to respond UI, because I don't when testing against:
data:text/html,<script>while(true){console.log("foo")}</script>

Comment 9

[Alexandre Poirot [:ochameau]]

Please ignore my needinfo, I did not realize this bug report involved executing the loop in the console...
This is a possible duplicate of bug 1903728.

Bug 1884377 report a similar issue, but without devtools involved, where the "slow script dialog" isn't fully reliable.
I actually came across this while investigating bug 1918267.

Comment 10

[Julian Descottes [:jdescottes]]

We can look at this from different angles:

• the slow script detection code doesn't seem to trigger in this case
• the console messages are capped (by default to 10000 messages) so we should be able to prune our packages so this size
• try to detect infinite loops and allow users to break on it

Comment 11

[Julian Descottes [:jdescottes]]

For the record, here's a profile of a while true + console log: https://share.firefox.dev/4fKLwih

Overall devtools code seems responsible for 2/3rd of time spent in the parent process, the rest seems to be the platform overhead.

Comment 12

[Alexandre Poirot [:ochameau]]

(In reply to Julian Descottes [:jdescottes] from comment #11)

For the record, here's a profile of a while true + console log: https://share.firefox.dev/4fKLwih

Overall devtools code seems responsible for 2/3rd of time spent in the parent process, the rest seems to be the platform overhead.

In the parent process we spend:

• 22% registering messages in the redux reducer (9% on areMessagesSimilar method)
• 15% adding ressources to ResourceCommand cache (probably something we could avoid, but not trivial as we overall expect ResourceCommand to cache everything. I did prevent that for tracer ressources)
• 9% instantiating ConsoleMessage out of the CONSOLE_MESSAGE ressources (would be nice if the frontend were consuming server objects as-is)
• 7% in CONSOLE_MESSAGE transformer

The janks seems to be happening when registering messages in the reducer and instantiating the ConsoleMessage objects.