Beginning on October 25th, 2016, Persona will no longer be an option for authentication on BMO. For more details see Persona Deprecated.
Last Comment Bug 690771 - Implement the debugger pause request (at the main loop)
: Implement the debugger pause request (at the main loop)
Product: Firefox
Classification: Client Software
Component: Developer Tools: Debugger (show other bugs)
: 9 Branch
: x86 Mac OS X
: P2 normal (vote)
: Firefox 13
Assigned To: Panos Astithas [:past]
: James Long (:jlongster)
Depends on:
Blocks: minotaur 711125
  Show dependency treegraph
Reported: 2011-09-30 07:39 PDT by Dave Camp (:dcamp)
Modified: 2012-02-10 07:28 PST (History)
2 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Working patch (21.69 KB, patch)
2011-12-15 09:23 PST, Panos Astithas [:past]
no flags Details | Diff | Splinter Review
Working patch v2 (21.85 KB, patch)
2012-01-10 07:27 PST, Panos Astithas [:past]
no flags Details | Diff | Splinter Review
Working patch v3 (21.81 KB, patch)
2012-01-23 01:04 PST, Panos Astithas [:past]
dcamp: review+
Details | Diff | Splinter Review
[in-fx-team] Working patch v3.1 (21.82 KB, patch)
2012-02-09 03:03 PST, Panos Astithas [:past]
past: review+
Details | Diff | Splinter Review

Description Dave Camp (:dcamp) 2011-09-30 07:39:30 PDT
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.
Comment 1 Panos Astithas [:past] 2011-09-30 08:38:39 PDT
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.
Comment 2 Panos Astithas [:past] 2011-12-14 09:22:03 PST
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.
Comment 3 Panos Astithas [:past] 2011-12-15 09:23:15 PST
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.
Comment 4 Panos Astithas [:past] 2012-01-10 07:27:37 PST
Created attachment 587303 [details] [diff] [review]
Working patch v2

Comment 5 Panos Astithas [:past] 2012-01-23 01:04:39 PST
Created attachment 590651 [details] [diff] [review]
Working patch v3

Rebased and refactored to take the latest superreview-requested changes into account.
Comment 6 Dave Camp (:dcamp) 2012-02-02 17:57:46 PST
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.
Comment 7 Panos Astithas [:past] 2012-02-08 08:57:55 PST
Try run:
Comment 8 Panos Astithas [:past] 2012-02-09 03:03:48 PST
Created attachment 595695 [details] [diff] [review]
[in-fx-team] Working patch v3.1

Updated patch metadata.
Comment 9 Panos Astithas [:past] 2012-02-10 02:08:28 PST
Comment 10 Tim Taubert [:ttaubert] 2012-02-10 07:28:55 PST

Note You need to log in before you can comment on or make changes to this bug.