When sitting at the main loop, a pause request should put the debuggee in a paused state as though it hit a breakpoint. A complete implementation of the pause request would actually interrupt a running thread, but we can leave that for another bug - it's much more difficult.
FWIW, the only way we can pause the debuggee currently that I can think of, is by delaying the return from an event handler (onDebuggerStatement, onNewScript, etc.), essentially communicating synchronously with the client. It's obviously a terrible idea, but it's the only way to solve the get-new-script-then-set-breakpoints problem, without waiting for a new API.
jimb explained how this should work to me. The 'interrupt' request type can be implemented by the debugger by just calling suppressEventHandling. Since the debugger and debuggee share the same event loop the debuggee is effectively paused when we make sure that no events can be delivered. The thread or tab client can have an isPaused method and an ensurePaused method that sends the interrupt request when not in a paused state. The setBreakpoint method can automatically call ensurePaused before setting the breakpoint as a bonus to the caller and a resume packet if it had to send an interrupt one.
Created attachment 582006 [details] [diff] [review] Working patch This implements the 'interrupt' protocol request that pauses the debuggee when it is in the main loop. An immediate use I found is to turn the Resume button into a toggle that pauses when the debuggee is running and resumes when the debuggee is paused. I'm also using it to manually enter the paused state for setting a breakpoint, but that will be automated in another bug. One other significant change I made, is that when entering a nested event loop I suspend timeouts and resume them when exiting. This should prevent debuggee setTimeout calls to fire while it is paused.
Created attachment 587303 [details] [diff] [review] Working patch v2 Rebased.
Created attachment 590651 [details] [diff] [review] Working patch v3 Rebased and refactored to take the latest superreview-requested changes into account.
Comment on attachment 590651 [details] [diff] [review] Working patch v3 There's hope that eventually an interrupt packet could actually interrupt running script (by poking the execution hook that the slowrun dialog uses), but obviously a lot of work needs to happen before that's the case (processing packets on another thread, for starters). This is perfect for now, just wanted to mention that in case I hadn't before.
Created attachment 595695 [details] [diff] [review] [in-fx-team] Working patch v3.1 Updated patch metadata.