Thanks for the descriptive example.  On 58.0.3015.0, I'm able to load the extension and inspect the background page.
- If I increase the timeout, DevTools can open before sources panel jumps to the "debugger;" line.  In this case, "Debugger is initialized" is logged, no alert is shown, no console message indicating "Got Debugger.paused"
- If I decrease the timeout, I can wait before opening DevTools.  Upon open, the alert() shows, I get the "Got Debugger.paused" console message, but the debugger doesn't pause since it passed while DT was closed

Seems to be a bug where Debugger is initialized while DevTools is open, but "debugger;" doesn't trigger Debugger.paused events.  dgozman@, kozy@, do you know if this logic changed recently?

I don't understand what's expected here.

The background.js tries to debug itself, getting Debugger.paused notification after "debugger;" statement inside of itself. I would say it should not be able to, since executing "_onEvent" in a paused JS context is somewhat strange.

Should you debug one extension from another one? Maybe from DevTools? Try out chrome://inspect/#extensions.

Hi, you asked a good question. It looks counterintuitive to pause the background page itself. But I have my reason to do so.

I need to do some native file IO operations (such as read file and write file) in synchronized way in my extension. To do so, in background page, I send message to native message handler (in native messaging host), then pause JavaScript execution in background page. Later native message handler sends back the result (of those native file IO operations). In the callback of those native file IO operations, I get chance to do some logic and send "Debugger.resume" command to debugger, so background page JavaScript engine will resume.

The tricky point here is, even when background page JavaScript engine is paused, native messages (the results of native file IO operations, coming from native messaging host) are still being handled.

I see your usecase. I think it's possible to overcome "self-debugging" with two extensions, one debugging another. WDYT?

> The tricky point here is, even when background page JavaScript engine is paused, native messages (the results of native file IO operations, coming from native messaging host) are still being handled.
Yes, they work for exactly the same reason "Debugger.paused" is dispatched to background page - they bypass the paused state and execute code directly. So, either they both work or they both don't, which means that it's unlikely your scenario will ever work.

Thanks for your quick reply.

> I see your usecase. I think it's possible to overcome "self-debugging" with two extensions, one debugging another. WDYT?
This is a good direction to try. Actually, I tried two extensions before, unfortunately, this way can't provide synchronized operations.

>Yes, they work for exactly the same reason "Debugger.paused" is dispatched to background page - they bypass the paused state and execute code directly. So, either they both work or they both don't, which means that it's unlikely your scenario will ever work.
This "self-debug" way works from Chromium 39 to Chromium 55. It doesn't work on Chromium 56. This should be caused by some change in Chromium 56. I guess this change in Chromium 56 is not an intended one, it's kind of side-effect of some other change. May I know is it possible to let Chromium 56 behave same as Chromium 55 in debugger area? Thanks.

Able to reproduce the issue on windows 7, Linux Ubuntu 14.04 and Mac 10.12.3.
This is regression issue broken in M56.Please find the bisect information as below

Narrow Bisect::
Good :: 56.0.2889.0  --   (build revision 424926)
Bad:: 56.0.2900.0  --  (build revision 427219)

Change Log::
https://chromium.googlesource.com/chromium/src/+log/cb923e53c99b3b91a190d184933ad028e0ac55d5..389e45df0fc5fcebbc651eea8daa72f3989914a6

Possible suspect::
https://chromium.googlesource.com/chromium/src/+/389e45df0fc5fcebbc651eea8daa72f3989914a6

rdevlin.cronin@ could you please look into this issue if it is related to your change,else please help us in finding the appropriate owner for this issue.

Thanks,

Hi, I tried it on Chromium 57 stable build, 57.0.2987.110. This problem still exists. If possible, please help to solve this issue. Our extension is blocked at Chromium 55, can't support later versions. Thanks.

Hi, I tried it on Chromium 58 stable build, 58.0.3029.81. This problem still exists. Any one can help?

Сlosing as per #5.