Bugzilla – Full Text Bug Listing
| Summary: | [Crossfire] update JSDT to use updated Crossfire breakpoints protocol | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [WebTools] JSDT | Reporter: | Grant Gayed <grant_gayed> | ||||||
| Component: | Debug | Assignee: | Grant Gayed <grant_gayed> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | Michael Rennie <Michael_Rennie> | ||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | thatnitind | ||||||
| Version: | unspecified | ||||||||
| Target Milestone: | 3.3 M6 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows XP | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
Grant Gayed
Created attachment 189839 [details]
patch
Michael can you have a look at this patch? It contains:
- the protocol changes for the setbreakpoint, clearbreakpoint and changebreakpoint requests
- additional changes in support of these, in particular:
-> when a script's source is retrieved, a persistent property is now set on its file indicating the url it originally came from
-> when a CFVirtualMachine is created all known JS breakpoints are now sent to the Crossfire server's global breakpoints table
-> a Map of breakpoint->Crossfire handles is now maintained in CFVirtualMachine
-> setting these handle values as an attribute on each breakpoint's IMarker would have been nicer, but doing so was triggering marker change notifications, so I fell back to creating the Map instead (maybe triggering the change notifications were fine?)
- NO protocol changes related to getbreakpoint or getbreakpoints as these are not yet being used
- a change completely unrelated to any of this, but too small to log a separate report for: the stepaction for stepping over should be "next", not "over"
Created attachment 190397 [details]
updated breakpoints patch
This updated patch was made a few days ago, after various other JSDT changes were made that caused the original patch in this report no longer apply.
fixed > 20110307 |