WebKit Bugzilla
New
Browse
Search+
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
39953
Web Inspector: support "Continue to Here" in debugger
https://bugs.webkit.org/show_bug.cgi?id=39953
Summary
Web Inspector: support "Continue to Here" in debugger
Yury Semikhatsky
Reported
2010-05-31 06:52:11 PDT
Support "Run To Cursor" functionality in script debugger.
Attachments
Patch
(10.19 KB, patch)
2010-06-02 07:04 PDT
,
Yury Semikhatsky
pfeldman
: review+
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Timothy Hatcher
Comment 1
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.)
Yury Semikhatsky
Comment 2
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.
Timothy Hatcher
Comment 3
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…
Yury Semikhatsky
Comment 4
2010-06-02 07:04:39 PDT
Created
attachment 57651
[details]
Patch
Pavel Feldman
Comment 5
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.
Yury Semikhatsky
Comment 6
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
Yury Semikhatsky
Comment 7
2010-06-02 08:20:50 PDT
Committed
r60567
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug