Community
Participate
Working Groups
When a 'suspend' response is received with success == true, JSDT immediately sets the thread's state to suspended and sends a 'backtrace' request. Neither of these should happen until the subsequent 'onBreak' event has been received. I see the current implementation sometimes work with the Firefox back-end because Firefox suspends promptly enough that it successfully responds to the 'backtrace' request. However IE does not suspend quite as quickly, so JSDT ends up in a state where it thinks it's suspended, which makes it not respond to the subsequent 'onBreak' event from IE.
looks like we should handle suspending the same way we do stepping, spawn a 'suspending' thread that listens for the onBreak event for a given timeout, that way we can give users feedback that the thread is trying to suspend, but not actually suspended.
we should also handle the case of delayed resuming.
Should there be a finite timeout when waiting for the resulting onBreak? It could validly take a long time for the onBreak to arrive if, for instance, there's currently a prompter being shown. I had assumed that the suspend command would be finished as soon as its response was received, and that the onBreak would just be handled separately whenever it happened to come in. I'm not sure if this approach would preclude giving the user the "I'm trying to suspend" feedback.
(In reply to comment #3) > Should there be a finite timeout when waiting for the resulting onBreak? It > could validly take a long time for the onBreak to arrive if, for instance, > there's currently a prompter being shown. > Its tough to say if the timeout should be finite, how long could it take to suspend? as you noted it be a very long time. > I had assumed that the suspend command would be finished as soon as its > response was received, and that the onBreak would just be handled separately > whenever it happened to come in. I'm not sure if this approach would preclude > giving the user the "I'm trying to suspend" feedback. The method would continue, as we would be spawning a new daemon thread and continuing on - see JavaScriptThread#suspendUnderlyingThread() for an example. Looking back at that code (JavaScriptThread#suspendUnderlyingThread()) I see we have the same challenge of a finite timeout as well, waiting for a suspend there can take a very long time. To simply test the idea of waiting for the onBreak event, we could remove the LOC state = SUSPENDED; from CFThreadReference line 168. The onBreak even is handled by default in the JavaScriptDebugTarget
Marking as P1, this seems important to address since the Suspend tool item is right there in a Debug view asking to be pressed by the user. I don't think that providing user feedback while waiting for the suspend is essential, but leaving the client in a state where it doesn't handle the resulting onBreak event effectively disables this functionality.
In a future release of Firebug, Crossfire support will be dropped completely in favour or JSD2 and RDP, as such no more bugs will be fixed for the Crossfire support. See: 1. https://wiki.mozilla.org/Firebug/WeeklyUpdates/2013-11-05#Crossfire 2. https://getfirebug.com/wiki/index.php/JSD2_Adoption 3. https://wiki.mozilla.org/Debugger
