Adding folks who might be able to help direct this issue.

+chrisha@, gab@, etienneb@ who are looking into the kinds of priority inversions that might make a hang like this happen.

@aklimov: do you have a page with a reliable repro?

To summarize, this is about adding a third button to the hang detections popup? Besides "Kill" and "Wait" there should be a "Debug in DevTools" button. This button should essentially pause the execution and jump to DevTools, be it Wasm or JavaScript code that is running.

binghamj@ WDYT about the idea?
yangguo@: I guess we already have all the machinery in place for that, this should "only" be about issuing a pause/breakpoint hit on button click?

This is about JS, chrisha&crew worry about Chrome induced C++ hangs.

"do you have a page with a reliable repro?"  - even simplest "while(1);" in the Developer Tools console will do. Chrome doesn't ask to pause/terminate the script. Killing the process (even the one associated with only that page) will cause to restart the whole app and all tabs.

I thought DevTools has a way to terminate JS already.

c#7: DevTools' Sources panel offers a Pause and Stop button from the Sources panel to pause/terminate JS.
[1] https://developers.google.com/web/updates/2018/04/devtools#stop

Seems like 2 scenarios:

1) DevTools is closed, hung renderer popup appears.
Adding a new "debug" button that opens DevTools sounds good to me.  We could log a Console message to make the Stop button [1] discoverable and/or automatically pause on startup.

2) DevTools is open.  Page stalls, but Chrome's "hang popup" is suppressed because it interferes w/ debugger stepping (  issue 684202  ).
One approach is to introduce a protocol event "targetUnresponsive" and send it to DevTools.  Then, it is up to the frontend to ignore it (if debugger was recently paused) or pause.

What do other DT folks think?


Side note: The hang detector delay seems long to me: 30s in Chrome vs 10s in Firefox.
Long ago, it seems it increased from 20s > 30s "temporarily", but nobody changed it back [2].

[2] https://chromium.googlesource.com/chromium/src/+/8ffca206c420fd3d25d25ae450ea96fa95e67be2

Adding pause button to unresponsive dialog is one of the oldest DevTools issue [1], we probably can merge these two bugs. We currently can process only little subset of commands inside JavaScript task. [2]
To run DevTools we need to refactor this code a little to allow a lot of other commands to be processed, e.g. Runtime.enable.

[1] crbug.com/74617
[2] https://cs.chromium.org/chromium/src/content/browser/devtools/devtools_session.cc?rcl=16cd8ea3ea5ff089130aa3a95f9978bc069ae6b0&l=23

Based on c#9, adding a "debug/pause" button to the unresponsive dialog is blocked on refactoring.
Covered in: crbug.com/74617

When DevTools is open, the dialog is not shown.  We should consider showing an informative console message whenever the dialog would be shown, or if any user's Console commands timeout.
To be covered in: crbug.com/838012

Should a while(1); statement in the console lock the entire browser (i.e., as opposed to the just the renderer process)?

c#11: No, it should not.  I was too quick to merge this crbug, sorry.  That does sounds like a separate, (non-DevTools-related?) issue.

I'm not able to repro Chrome closing all other tabs when killing a single page's process, nor can I repro browser-wide hang.

The only workaround is to reload the page with the devtools opened.