Reputation: 10830
Preface: don't ask for sample code. This is not a sample code kind of question. If there is a better stack exchange place to be asking this, I am happy to oblige, but a search revealed no such place, so here I am, humbly looking for help.
So, my application receives data from a websocket to a web worker, and then from the web worker to the main application. The application contains, for example, view updating methods. Sometimes these have bugs, so I use the dev tools to set a breakpoint, as one does!
However, while the breakpoint has "paused" the application, the flow of data has not stopped. And as a background process of the browser itself (ie. out of my control), if these are hitting the same breakpoint, they wait around in a queue for processing. The browser itself creates a backlog of times the breakpoint has been hit.
Consequently, you can disable the breakpoint, click "resume execution", and it will go to the next backlogged time a breakpoint was hit. There's no concept of "that breakpoint doesn't exist anymore" because the breakpoint WAS there when the backlog was created.
Net result: if the breakpoint is hit, say 50 times while debugging, I have to click 50 times before I can actually resume execution of the application.
Can anybody spot something I'm doing wrong or missing? Or is there a hidden feature flag that I can set so that the backlog is not created? Or an obvious "always resume" button that once clicked will just hammer its way through any of the backlogged breakpoints?
Side note: you can't even simply (and quickly) refresh the page, because the "backlog" prevents it.
Upvotes: 0
Views: 53
Reputation: 26017
Or an obvious "always resume" button that once clicked will just hammer its way through any of the backlogged breakpoints?
Long-press the Resume button and select Force script execution. Note: I'm not saying it's obvious, but I think this is what you want.
The Deactivate breakpoints button might work, too.
Upvotes: 1