Bug 39953 - Web Inspector: support "Continue to Here" in debugger
Summary: Web Inspector: support "Continue to Here" in debugger
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Web Inspector (Deprecated) (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-05-31 06:52 PDT by Yury Semikhatsky
Modified: 2010-06-02 08:20 PDT (History)
9 users (show)

See Also:


Attachments
Patch (10.19 KB, patch)
2010-06-02 07:04 PDT, Yury Semikhatsky
pfeldman: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Yury Semikhatsky 2010-05-31 06:52:11 PDT
Support "Run To Cursor"  functionality in script debugger.
Comment 1 Timothy Hatcher 2010-05-31 08:17:48 PDT
Please describe this, I don't know what this means. (I have some wild guesses but I'll let you go first.)
Comment 2 Yury Semikhatsky 2010-05-31 23:27:08 PDT
It's like a one-time breakpoint. I think it'd be best to describe it as a step in/over/out counterpart that allows to continue program until given statement is reached. When you're debugging a program you may want to inspect its state at some execution point but you might not want to set a regular breakpoint which would cause the program to stop every time when the control flow reaches that line. MS Visual Studio and Eclipse provide such capability, I don't see it in Xcode though.
Comment 3 Timothy Hatcher 2010-05-31 23:47:58 PDT
Ah. Xcode has this, if you right click in the line number column you will see "Continue to Here".

I think Xcode's wording is more clear than "Run To Cursor". Cursor can mean so many things…
Comment 4 Yury Semikhatsky 2010-06-02 07:04:39 PDT
Created attachment 57651 [details]
Patch
Comment 5 Pavel Feldman 2010-06-02 07:49:36 PDT
Comment on attachment 57651 [details]
Patch

Overall, this looks good, so I am open to landing this. However, the change uncovers some problems with our design in the area of passing numerous callbacks into SourceFrame.
As we discussed offline, I would suggest the following refactorings:
1. Make SourceFrame BreakpointManager's listener
1.1. Make SourceFrame responsible for filling breakpoints on creation (few addBreakpoint snippets will go away from ScriptsPanel)
2. Remove sourceFrameForScriptOrResource from the scripts panel.
Comment 6 Yury Semikhatsky 2010-06-02 08:15:50 PDT
(In reply to comment #5)
> (From update of attachment 57651 [details])
> Overall, this looks good, so I am open to landing this. However, the change uncovers some problems with our design in the area of passing numerous callbacks into SourceFrame.
> As we discussed offline, I would suggest the following refactorings:
> 1. Make SourceFrame BreakpointManager's listener
> 1.1. Make SourceFrame responsible for filling breakpoints on creation (few addBreakpoint snippets will go away from ScriptsPanel)
> 2. Remove sourceFrameForScriptOrResource from the scripts panel.

Filed a new bug on this: https://bugs.webkit.org/show_bug.cgi?id=40063
Comment 7 Yury Semikhatsky 2010-06-02 08:20:50 PDT
Committed r60567