STR:

1. Load http://janodvarko.cz/tests/debugger/workers/
2. Open DevTools Toolbox, select the Debugger panel
3. Create Event Listener BP: Script -> Script First Statement
4. Create an expressions in the Watch Expressions panel: "state" (I think it should be invalid)
5. Click the "Start Worker" in the Test Case #1 (but page reload should also be fine)
6. The Debugger should pause
7. Click "Resume" and watch the source tabs, tabs like "Source538" are created => BUG

Honza

Also, the same source can be opened multiple times - resulting with mutliple source tabs with the same title. When selecting one of those duplicated tabs, all of them are selected.

The situation here is that we have a couple of features executing some javascript bits:

• watch expressions
• log and condition breakpoints
• eager evaluation
• console evaluation
  But also in other panels:
  https://searchfox.org/mozilla-central/search?q=scriptCommand.execute&path=devtools%2Fclient&case=true&regexp=false
• DOM Panel window getter
• DOM Inspector "use in console"
• CSS Warning get matching elements
• Console "store as global"
• Console "copy object"

Log and conditional breakpoints are the only one having a very explicit "hideFromDebugger" flag, introduced in:
https://phabricator.services.mozilla.com/D138610
which should prevent spawning Debugger.Source.
This save lots of cycle in the server, but even more in the client by preventing emitting SOURCE resources.
But this trick doesn't prevent hitting breakpoints. If the log or conditional breakpoint calls some code triggering a breakpoint, the debugger will pause on it! (Note that chrome doesn't pause)

For some unknown reason, eager evaluation do not spawn Debugger.Object.
And there is some explicit code to prevent hitting breakpoints when evaluating them:
https://searchfox.org/mozilla-central/rev/27e4816536c891d85d63695025f2549fd7976392/devtools/server/actors/thread.js#309

We should probably use a common pattern for all these usecases and both prevent emitting Debugger.Source and ensure disabling breakpoints when evaluating them.

Note that inline preview is also impacted:
https://searchfox.org/mozilla-central/search?q=client.evaluate%28&path=debugger&case=true&regexp=false

There is probably something special to be done around conditional and log breakpoints.
Exceptions shouldn't be ignored. In the past, in bug 983469 we explicitly tried to pause on them when they throw.

In the current revision, I still do, but I prevent "pause on exception" to be triggerred by exception in conditional breakpoint.
I think it is fine and expected as soon as we still pause on them when they throw, right?

Conditional breakpoints weren't preventing breakpoints from being hit and could pause in many unexpected ways.
It requires some tweaks regarding disableBreaks argument as we still have to notify about pause on exception
to ensure notifying the user when the condition throws.
Introduce the reportExceptionsWhenBreaksAreDisabled flag for this.

Otherwise it looks like we were not having test actually asserting the the condition breakpoint
actually worked for real and paused page execution. We were only having test covering the UI state.

https://hg.mozilla.org/mozilla-central/rev/949d288773b8
https://hg.mozilla.org/mozilla-central/rev/eef8bff2d611