Closed Bug 1828026 Opened 1 year ago Closed 11 months ago

Infinite loop with an early console warning on load

Categories

(DevTools :: Console, defect, P2)

Product:
DevTools
Component:
Console
Version:
Firefox 112
Type:
defect

Tracking

(relnote-firefox 113+, firefox-esr102 unaffected, firefox113 verified, firefox114 verified, firefox115 verified)

Status:
VERIFIED FIXED
Milestone:
115 Branch
Tracking Flags:
Tracking Status
relnote-firefox --- 113+
firefox-esr102 --- unaffected
firefox113 --- verified
firefox114 --- verified
firefox115 --- verified

People

(Reporter: darsh, Assigned: nchevobbe)

References

(Regression)

Details

(Keywords: regression)

Attachments

(5 files, 1 obsolete file)

2023-04-12-07-37-16-911af7.png
263.10 KB, image/png
Details
Firefox 2023-04-22 13.10 profile.json(1).gz
8.45 MB, application/x-gzip
Details
memory-report.json.gz
131.62 KB, application/x-gzip
Details
Support RAW.txt
72.97 KB, text/plain
Details
Bug 1828026 - [devtools] Bail in ConsoleMessageWatcher#watch if passed frame target has a null window. r=jdescottes.
48 bytes, text/x-phabricator-request
pascalc
: approval-mozilla-beta+
RyanVM
: approval-mozilla-release+
Details | Review

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/112.0

Steps to reproduce:

Since version 111, I have been facing a great memory leak problem in Inspect Mode.
I use Datatables jQuery plugin and I develop only the backend (PHP) for the same front-end since 2017, almost for 6 years.
Only since Firefox version 111, When I use Inspect Mode and browse to a page with dataTables (Data are added using Ajax Call), The page freezes and memory usage and CPU starts to go up without a limit. And the only want to get out of it is by killing the process. I waited for the new update, probably my problem was logged, but I found it still there, so I wanted to officially report it.

Actual results:

The browser freeze. High CPU usage. Infinite RAM consumption.

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

Component: Untriaged → Performance
Product: Firefox → Core

This bug was moved into the Performance component.

:darsh, could you make sure the following information is on this bug?

  • For slowness or high CPU usage, capture a profile with http://profiler.firefox.com/, upload it and share the link here.
  • For memory usage issues, capture a memory dump from about:memory and attach it to this bug.
  • Troubleshooting information: Go to about:support, click "Copy raw data to clipboard", paste it into a file, save it, and attach the file here.

If the requested information is already in the bug, please confirm it is recent.

Thank you.

Flags: needinfo?(darsh)

A memory report or steps to reproduce will be needed to make progress here. Maybe somebody working on DevTools can help figure out some steps to reproduce.

Component: Performance → General
Product: Core → DevTools

(In reply to Andrew McCreight [:mccr8] from comment #3)

A memory report or steps to reproduce will be needed to make progress here. Maybe somebody working on DevTools can help figure out some steps to reproduce.

In order to be able to continue my work, I had to downgrade to version 110.0.1 x64.
I have to upgrade to 112 again to be able to reproduce it.
However, This only happens when I have Inspect Mode On, then browse to or refresh a page which has "Datatable" loaded via Ajax and then, The tab freezes and process starts to use high CPU and keep adding memory until memory is full.
Closing Inspect mode doesn't help, the page still frozen and Inspect Mode is partially closed (Empty, but the bottom window is irresponsible).
The only way to be able to unfreeze the browser, is to kill the sub-process from task manager, and the previous page is loaded when I click on "Restore this tab" in tab crash page.
I will try to re-update and collect profile data.
By the way: about:memory also was frozen during the issue.

Attached file memory-report.json.gz —
Attached file Support RAW.txt —
Flags: needinfo?(darsh)

(In reply to Andrew McCreight [:mccr8] from comment #3)

A memory report or steps to reproduce will be needed to make progress here. Maybe somebody working on DevTools can help figure out some steps to reproduce.

I have created a profile recording and uploaded memory report and raw troubleshooting information.

Hello, thanks for the report
Unfortunately we don't have much in the profile you attached, could you try again, starting to profile before opening devtools and stop profiling as soon as you hit the issue ?
Note that with https://profiler.firefox.com you can upload the profile so you can share it with a simple URL.

Also could you try to run https://mozilla.github.io/mozregression/ so we can get an idea of what regressed this?

It looks like you can't share the page it's happening on? Maybe you could build a simple public page which reproduces the issue? Or if not, share what's in the network response?

Flags: needinfo?(darsh)

I'm sorry it took long to reply. I downgraded to version 110 to be able to continue my work and I needed some work-free time to re-upgrade and provide more information.

(In reply to Nicolas Chevobbe [:nchevobbe] from comment #9)

It looks like you can't share the page it's happening on? Maybe you could build a simple public page which reproduces the issue? Or if not, share what's in the network response?

I'm afraid that I can't do that right now. But I may be able to do it in case we couldn't found the issue.

(In reply to Nicolas Chevobbe [:nchevobbe] from comment #9)

Also could you try to run https://mozilla.github.io/mozregression/ so we can get an idea of what regressed this?

I have ran the steps and that's what I got. I hope it's enough. I will try to run the profiler and share the results as well but usually everything freeze the bug starts.
88e05166 was the last good build. Also Bug - 1814613 is related to devTools where the issue happens, so I believe it's the real change that cased the bug.

2023-05-09T16:01:34.589000: INFO : Narrowed integration regression window from [88e05166, 97a75b42] (4 builds) to [88e05166, ba79613c] (2 builds) (~1 steps left)
2023-05-09T16:01:34.600000: DEBUG : Starting merge handling...
2023-05-09T16:01:34.600000: DEBUG : Using url: https://hg.mozilla.org/integration/autoland/json-pushes?changeset=ba79613c14b780ccfa1daed7889e6bf6528006a5&full=1
2023-05-09T16:01:34.600000: DEBUG : redo: attempt 1/3
2023-05-09T16:01:34.600000: DEBUG : redo: retry: calling _default_get with args: ('https://hg.mozilla.org/integration/autoland/json-pushes?changeset=ba79613c14b780ccfa1daed7889e6bf6528006a5&full=1',), kwargs: {}, attempt #1
2023-05-09T16:01:34.602000: DEBUG : urllib3.connectionpool: Resetting dropped connection: hg.mozilla.org
2023-05-09T16:01:36.196000: DEBUG : urllib3.connectionpool: https://hg.mozilla.org:443 "GET /integration/autoland/json-pushes?changeset=ba79613c14b780ccfa1daed7889e6bf6528006a5&full=1 HTTP/1.1" 200 None
2023-05-09T16:01:36.234000: DEBUG : Found commit message:
Bug 1814613 - [devtools] Avoid firing DOCUMENT_EVENT for previous background page when reloading an add-on. r=devtools-reviewers,nchevobbe

This can lead to various issues as we were getting two sets of DOCUMENT_EVENT's when reloading an add-on.

Hopefully, this will be simplier to handle once we move WebExtension to EFT
and WindowGlobalTarget will be unique per document and their instantiation is solely
controlled by the watcher codebase.
We might still have to be careful to ignore this spurious about:blank document.

Differential Revision: https://phabricator.services.mozilla.com/D168045

2023-05-09T16:01:36.234000: DEBUG : Did not find a branch, checking all integration branches
2023-05-09T16:01:36.234000: INFO : The bisection is done.
2023-05-09T16:01:36.234000: INFO : Stopped

Flags: needinfo?(darsh)

Considering the Bug you found, it could have something to do with iframes being reloaded. Is this the case when your data table gets updated?
If you can find the time to share an example it would really help.

  • will build a test case recreating iframes in a loop to check the memory impact.
Flags: needinfo?(jdescottes)
Flags: needinfo?(darsh)

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

Considering the Bug you found, it could have something to do with iframes being reloaded. Is this the case when your data table gets updated?
If you can find the time to share an example it would really help.

  • will build a test case recreating iframes in a loop to check the memory impact.

Hello Julian.
I have built this page to help you re-produce the issue: https://shorturl.at/ktBIU

Steps:
Open the above link, then open devTools (Right Click -> Inspect).
While Inspect is open, navigate to the first dataTable page "Branches" from left menu.
After the page finish loading and Inspect Mode is still open, navigate to the second dataTable page "Branches Notifications" from left menu.
Then, the page will freeze and the CPU and RAM consumption will start to increase even for a couple of minutes after tab close.

PS: When I started the case, the tab was refusing to close, and I had to kill it from process manager. But now it can be closed.

Flags: needinfo?(darsh)

Perfect I can reproduce this on your test page! Thanks a lot!

Keeping the needinfo to investigate.

Severity: -- → S3
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P2

I can confirm this was "regressed" by Bug 1814613, but before this bug we actually had errors in DevTools:

JavaScript error: resource://devtools/server/actors/targets/window-global.js, line 1684: NS_ERROR_NOT_AVAILABLE: Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIDocShell.domWindow]
JavaScript error: resource://devtools/server/actors/targets/window-global.js, line 414: NS_ERROR_NOT_AVAILABLE: Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIDocShell.domWindow]
JavaScript error: resource://devtools/server/actors/targets/window-global.js, line 414: NS_ERROR_NOT_AVAILABLE: Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIDocShell.domWindow]
Handler function threw an exception: [Exception... "Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIDocShell.domWindow]" nsresult: "0x80040111 (NS_ERROR_NOT_AVAILABLE)" location: "JS frame :: resource://devtools/server/actors/targets/window-global.js :: watch :: line 1636" data: no]
Stack: watch@resource://devtools/server/actors/targets/window-global.js:1636:28
_watchDocshells@resource://devtools/server/actors/targets/window-global.js:770:28
initialize/<@resource://devtools/server/actors/targets/window-global.js:340:42
exports.makeInfallible/<@resource://devtools/shared/ThreadSafeDevToolsUtils.js:103:22
Line: 1636, column: 0
console.error: ({})

With the fix from Bug 1814613, we no longer have this error, but it seems that instead we have an infinite loop while handling log messages:

notifyResources@resource://devtools/server/actors/targets/target-actor-mixin.js:82:12
onConsoleAPICall@resource://devtools/server/actors/resources/console-messages.js:47:18
onConsoleAPILogEvent@resource://devtools/server/actors/webconsole/listeners/console-api.js:113:10
CS_recordEvent@resource://gre/modules/ConsoleAPIStorage.jsm:172:19
_emit@resource://devtools/shared/event-emitter.js:257:19
emit@resource://devtools/shared/event-emitter.js:186:18
emit@resource://devtools/shared/event-emitter.js:330:18
notifyResources@resource://devtools/server/actors/targets/target-actor-mixin.js:82:12
onConsoleAPICall@resource://devtools/server/actors/resources/console-messages.js:47:18
onConsoleAPILogEvent@resource://devtools/server/actors/webconsole/listeners/console-api.js:113:10
CS_recordEvent@resource://gre/modules/ConsoleAPIStorage.jsm:172:19
_emit@resource://devtools/shared/event-emitter.js:257:19
emit@resource://devtools/shared/event-emitter.js:186:18
emit@resource://devtools/shared/event-emitter.js:330:18
notifyResources@resource://devtools/server/actors/targets/target-actor-mixin.js:82:12
onConsoleAPICall@resource://devtools/server/actors/resources/console-messages.js:47:18
onConsoleAPILogEvent@resource://devtools/server/actors/webconsole/listeners/console-api.js:113:10
CS_recordEvent@resource://gre/modules/ConsoleAPIStorage.jsm:172:19
_emit@resource://devtools/shared/event-emitter.js:257:19
emit@resource://devtools/shared/event-emitter.js:186:18
emit@resource://devtools/shared/event-emitter.js:330:18
notifyResources@resource://devtools/server/actors/targets/target-actor-mixin.js:82:12
onConsoleAPICall@resource://devtools/server/actors/resources/console-messages.js:47:18
onConsoleAPILogEvent@resource://devtools/server/actors/webconsole/listeners/console-api.js:113:10
CS_recordEvent@resource://gre/modules/ConsoleAPIStorage.jsm:172:19
_emit@resource://devtools/shared/event-emitter.js:257:19
emit@resource://devtools/shared/event-emitter.js:186:18
emit@resource://devtools/shared/event-emitter.js:330:18

Keywords: regression
Regressed by: 1814613

Set release status flags based on info from the regressing bug 1814613

status-firefox113: --- → affected
status-firefox114: --- → affected
status-firefox115: --- → affected
status-firefox-esr102: --- → unaffected

It seems that the issue is that we fail to emit a console message, a console.warn:

Deprecation warning: moment().subtract(period, number) is deprecated. Please use moment().subtract(number, period).

We fail to do that because the JSWindowActor can't communicate at that time (too early?) and this ends up being caught by the try catch of the event-emitter at https://searchfox.org/mozilla-central/rev/445a5ab684b73eb56d807d0f3b2fabcc85a7c3dd/devtools/shared/event-emitter.js#255-260

        } catch (ex) {
          // Prevent a bad listener from interfering with the others.
          console.error(ex);
          const msg = ex + ": " + ex.stack;
          dump(msg + "\n");
        }

And the console.error in the catch block will also be considered as a resource which we need to emit, which fails again for the same reason, and so we end up with an infinite loop.

Here's a more complete stacktrace:

onConsoleAPICall (resource://devtools/server/actors/resources/console-messages.js#50)
onConsoleAPILogEvent (resource://devtools/server/actors/webconsole/listeners/console-api.js#113)
CS_recordEvent (resource://gre/modules/ConsoleAPIStorage.jsm#172)
_emit (resource://devtools/shared/event-emitter.js#257)
emit (resource://devtools/shared/event-emitter.js#186)
emit (resource://devtools/shared/event-emitter.js#330)
notifyResources (resource://devtools/server/actors/targets/base-target-actor.js#77)
onConsoleAPICall (resource://devtools/server/actors/resources/console-messages.js#50)
onConsoleAPILogEvent (resource://devtools/server/actors/webconsole/listeners/console-api.js#113)
CS_recordEvent (resource://gre/modules/ConsoleAPIStorage.jsm#172)
_emit (resource://devtools/shared/event-emitter.js#257)
emit (resource://devtools/shared/event-emitter.js#186)
emit (resource://devtools/shared/event-emitter.js#330)
notifyResources (resource://devtools/server/actors/targets/base-target-actor.js#77)
onConsoleAPICall (resource://devtools/server/actors/resources/console-messages.js#50)
onConsoleAPILogEvent (resource://devtools/server/actors/webconsole/listeners/console-api.js#113)
CS_recordEvent (resource://gre/modules/ConsoleAPIStorage.jsm#172)
_emit (resource://devtools/shared/event-emitter.js#257)
emit (resource://devtools/shared/event-emitter.js#186)
emit (resource://devtools/shared/event-emitter.js#330)
notifyResources (resource://devtools/server/actors/targets/base-target-actor.js#77)
onConsoleAPICall (resource://devtools/server/actors/resources/console-messages.js#50)
onConsoleAPILogEvent (resource://devtools/server/actors/webconsole/listeners/console-api.js#113)
CS_recordEvent (resource://gre/modules/ConsoleAPIStorage.jsm#172)
Z (https://ffbug.shoman.net/system/assets/global/plugins/moment.min.js#6)
_ (https://ffbug.shoman.net/system/assets/global/plugins/moment.min.js#6)
Za (https://ffbug.shoman.net/system/assets/global/plugins/moment.min.js#6)
handleDateRangePickers (https://ffbug.shoman.net/system/assets/pages/scripts/components-date-time-pickers.js#68)
init (https://ffbug.shoman.net/system/assets/pages/scripts/components-date-time-pickers.js#240)
<anonymous> (https://ffbug.shoman.net/system/assets/pages/scripts/components-date-time-pickers.js#249)
i (https://ffbug.shoman.net/system/assets/global/plugins/jquery.min.js#2)
fireWith (https://ffbug.shoman.net/system/assets/global/plugins/jquery.min.js#2)
ready (https://ffbug.shoman.net/system/assets/global/plugins/jquery.min.js#2)
K (https://ffbug.shoman.net/system/assets/global/plugins/jquery.min.js#2)
promise (https://ffbug.shoman.net/system/assets/global/plugins/jquery.min.js#2)
<anonymous> (https://ffbug.shoman.net/system/assets/global/plugins/jquery.min.js#2)
<anonymous> (https://ffbug.shoman.net/system/assets/global/plugins/jquery.min.js#2)
<anonymous> (https://ffbug.shoman.net/system/assets/global/plugins/jquery.min.js#2)

I can see 2 items to clarify:

  • why is the JSWindowActor unable to communicate with the parent process at this point in time
  • why is this console.error from devtools code considered as a regular console resource relevant for the content toolbox
Flags: needinfo?(jdescottes)
Component: General → Console
Summary: Memory leak in Inspect Mode → Infinite loop with an early console warning on load

Nicolas, do you know where we are supposed to filter out messages from devtools actors using "console" for the content toolbox?
In this case we seem to have an infinite loop in the content toolbox because of a DevTools console.error. I'm wondering if we are overall emitting many resources for devtools messages which only get filtered very late in the process?

Flags: needinfo?(nchevobbe)

Note that we already have a workaround for this specific error in https://searchfox.org/mozilla-central/rev/445a5ab684b73eb56d807d0f3b2fabcc85a7c3dd/devtools/server/connectors/js-window-actor/DevToolsFrameChild.sys.mjs#239-261

  try {
    this.sendAsyncMessage("DevToolsFrameChild:destroy", {
      actors: [
        {
          watcherActorID,
          form,
        },
      ],
      options,
    });
  } catch (e) {
    // Ignore exception when the JSWindowActorChild has already been destroyed.
    // We often try to emit this message while the WindowGlobal is in the process of being
    // destroyed. We eagerly destroy the target actor during reloads,
    // just before the WindowGlobal starts destroying, but sendAsyncMessage
    // doesn't have time to complete and throws.
    if (
      !e.message.includes("JSWindowActorChild cannot send at the moment")
    ) {
      throw e;
    }
  }
});

:ochameau, since you are the author of the regressor, bug 1814613, could you take a look?

For more information, please visit BugBot documentation.

Flags: needinfo?(poirot.alex)

Clearing the ni, the regressor bug is not extremely relevant here.

Flags: needinfo?(poirot.alex)

The issue is that here, when we instantiate the ConsoleAPIListener https://searchfox.org/mozilla-central/rev/1f0f0e29a7bcb6d6dc82fe628861bccc2066a98e/devtools/server/actors/resources/console-messages.js#69-70,73,76

const window =
  targetActor.targetType === Targets.TYPES.FRAME &&
...
    ? targetActor.window
...
const listener = new ConsoleAPIListener(window, onConsoleAPICall, {

we do have a frame target, as expected, but the window is null.
The window is retrieved from the docShell https://searchfox.org/mozilla-central/rev/1f0f0e29a7bcb6d6dc82fe628861bccc2066a98e/devtools/server/actors/targets/window-global.js#457-461

get window() {
  return this.docShell && !this.docShell.isBeingDestroyed()
    ? this.docShell.domWindow
    : null;
}

and in this case, this.docShell.isBeingDestroyed() is true, so we get a null window.
Then the ConsoleAPIListener does not have a innerWindowId to match on, and so let all the messages go through, creating the infinite loop

We could have a simple fix for the console message infinite loop by not setting the ConsoleMessageWatcher if we expect messages for a given window but the target window is null :

diff --git a/devtools/server/actors/resources/console-messages.js b/devtools/server/actors/resources/console-messages.js
--- a/devtools/server/actors/resources/console-messages.js
+++ b/devtools/server/actors/resources/console-messages.js
@@ -66,12 +66,15 @@ class ConsoleMessageWatcher {
     // And also ignore WebExtension as we will filter out only by addonId, which is
     // passed via consoleAPIListenerOptions. WebExtension may have multiple windows/documents
     // but all of them will be flagged with the same addon ID.
-    const window =
+    const messagesShouldMatchWindow =
       targetActor.targetType === Targets.TYPES.FRAME &&
       targetActor.typeName != "parentProcessTarget" &&
-      targetActor.typeName != "webExtensionTarget"
-        ? targetActor.window
-        : null;
+      targetActor.typeName != "webExtensionTarget";
+    const window = messagesShouldMatchWindow ? targetActor.window : null;
+
+    if (messagesShouldMatchWindow && !window) {
+      return;
+    }
 
     const listener = new ConsoleAPIListener(window, onConsoleAPICall, {
       excludeMessagesBoundToWindow: isTargetActorContentProcess,

Not sure if we should have a broader fix that would prevent watching resources for a target with a docShell being destroyed

Nice analysis!

Yes it sounds important to ensure we have a window when we expect one in ConsoleMessageWatcher (and may be other console watchers having the same window pattern?).

I also agree that we should bail out earlier.
Is the ConsoleMessageWatcher being instantiated from this callsite?
https://searchfox.org/mozilla-central/rev/1f0f0e29a7bcb6d6dc82fe628861bccc2066a98e/devtools/server/connectors/js-window-actor/DevToolsFrameChild.sys.mjs#290
If yes, I would be curious if it then comes from instantiate or receiveMessage. In any case, we could probably have some check the earliest in the JSWindowActor. I suspect that this.didDestroy may be false and we might have to check the this.docShell...

Attachment #9333090 - Attachment is obsolete: true

I created a smaller test case here: https://ffx-devtools-short-lived-iframe-document-write.glitch.me/

document.querySelector("button").addEventListener("click", function () {
  var iframe = document.createElement("iframe");
  document.body.appendChild(iframe);

  var iframeDoc = iframe.contentDocument;
  iframeDoc.open();
  iframeDoc.write(
    "<html><head></head><body>12<script>console.warn('oops')</script></body></html>"
  );
  iframeDoc.close();
  document.body.removeChild(iframe);
});

so basically, creating an iframe and adding it to the body, using document.write on it with markup that will emit a console message, and then removing the iframe from the body right away

Assignee: nobody → nchevobbe
Attachment #9333324 - Attachment description: WIP: Bug 1828026 - [devtools] Bail in ConsoleMessageWatcher#watch if passed frame target has a null window. → Bug 1828026 - [devtools] Bail in ConsoleMessageWatcher#watch if passed frame target has a null window. r=jdescottes.
Status: NEW → ASSIGNED
Pushed by nchevobbe@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/ec2da5df1a0e
[devtools] Bail in ConsoleMessageWatcher#watch if passed frame target has a null window. r=jdescottes,devtools-reviewers.

https://hg.mozilla.org/mozilla-central/rev/ec2da5df1a0e

Status: ASSIGNED → RESOLVED
Closed: 11 months ago
status-firefox115: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → 115 Branch

Comment on attachment 9333324 [details]
Bug 1828026 - [devtools] Bail in ConsoleMessageWatcher#watch if passed frame target has a null window. r=jdescottes.

Beta/Release Uplift Approval Request

  1. Open the console
  2. Click on the Click here button

-> Firefox should not freeze

  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): A few lines, devtools only fix
  • String changes made/needed:
  • Is Android affected?: No
Attachment #9333324 - Flags: approval-mozilla-beta?
Flags: qe-verify+
QA Whiteboard: [qa-triaged]

I have reproduced this issue using Firefox 111.0 and Firefox 113.0 on Win 10, with the link from comment 12.
I can confirm this issue is fixed, I verified using latest nightly Fx 115.0a1 on Win 10, macOS 12 and Ubuntu 22, it is no more infinite load issue.

status-firefox115: fixed → verified

Comment on attachment 9333324 [details]
Bug 1828026 - [devtools] Bail in ConsoleMessageWatcher#watch if passed frame target has a null window. r=jdescottes.

Approved for 114 beta 5, thanks.

Attachment #9333324 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

Did you want to nominate this for Release approval for next week's planned dot release? Go ahead and do so if yes!

Flags: needinfo?(nchevobbe)

I can confirm this issue is fixed, I verified using Firefox 114.0b5 on Win 10, macOS 12 and Ubuntu 22.

status-firefox114: fixed → verified

Comment on attachment 9333324 [details]
Bug 1828026 - [devtools] Bail in ConsoleMessageWatcher#watch if passed frame target has a null window. r=jdescottes.

Beta/Release Uplift Approval Request

  1. Open the console
  2. Click on the Click here button

-> Firefox should not freeze

  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): A few lines, devtools only fix, already uplifted to beta
  • String changes made/needed:
  • Is Android affected?: No
Flags: needinfo?(nchevobbe)
Attachment #9333324 - Flags: approval-mozilla-release?

(In reply to Ryan VanderMeulen [:RyanVM] from comment #35)

Did you want to nominate this for Release approval for next week's planned dot release? Go ahead and do so if yes!

sure, thanks for the ping!

Comment on attachment 9333324 [details]
Bug 1828026 - [devtools] Bail in ConsoleMessageWatcher#watch if passed frame target has a null window. r=jdescottes.

Approved for 113.0.2.

Attachment #9333324 - Flags: approval-mozilla-release? → approval-mozilla-release+

Added to the 113.0.2 release notes:

Fixed a bug which could cause Firefox to freeze on some pages when loading them with the Developer Tools Web Console open

relnote-firefox: --- → 113+

Verified as fixed on Firefox 113.0.2 (20230522134052) across the following platforms: Win 11, macOS 11, Ubuntu 22.04.

Status: RESOLVED → VERIFIED
status-firefox113: fixed → verified
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: