| Summary: | Hitting a breakpoint during a step causes debug buttons to disable | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [WebTools] JSDT | Reporter: | Michael Rennie <Michael_Rennie> | ||||
| Component: | Debug | Assignee: | Michael Rennie <Michael_Rennie> | ||||
| Status: | RESOLVED FIXED | QA Contact: | Simon Kaegi <simon_kaegi> | ||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | thatnitind | ||||
| Version: | 3.3 | ||||||
| Target Milestone: | 3.3 M3 | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| Bug Depends on: | |||||||
| Bug Blocks: | 327270, 327278 | ||||||
| Attachments: |
|
||||||
Created attachment 180077 [details]
fix
patch also has an update to not make multiple calls to JavaScriptThread.resumeUnderlyingThread() as well as avoid sending a RESUME DebugEvent when not asked for.
applied patch to HEAD |
code from HEAD debug the following snippet: function Func(fval){ this.__defineSetter__("value", function(val){ value = val; //bp here }); } var myfunc = new Func("foo"); //bp here myfunc.value = "foo2"; and step over until you hit the breakpoint in __defineSetter__. Notice that all of the debugging buttons (step over / into / out) are all disabled. Taking a quick look revealed that we still think we are stepping in this case, so when the commands poll for enablement (canStep) we say no. We should be handling the case of hitting a breakpoint while stepping - we already handle resuming while stepping.