DevTools: start in the beginning of the line upon "continue to here".

DevTools: start in the beginning of the line upon "continue to here".

R=dgozman
BUG=495202
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=197988

[dgozman, 2015-06-29 12:11:43]

lgtm

[pfeldman, 2015-06-29 12:25:20]

The CQ bit was checked by pfeldman@chromium.org

[commit-bot: I haz the power, 2015-06-29 12:25:29]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1214973002/1

[commit-bot: I haz the power, 2015-06-29 14:36:29]

Committed patchset #1 (id:1) as
https://src.chromium.org/viewvc/blink?view=rev&revision=197988

[wes, 2015-06-29 17:35:09]

This prevents users from stepping between statements on a single line - a useful
feature to have when working with minified files, and something the debugger
fully supports. It would be better that this is left unaltered and the algorithm
for selecting the 'closest' break location in v8 be changed to match the desired
behavior of selecting one statement earlier than currently is chosen with
nonzero column numbers. It can be found here:
https://code.google.com/p/chromium/codesearch#chromium/src/v8/src/debug.cc&l=223
and here
https://code.google.com/p/chromium/codesearch#chromium/src/v8/src/debug.cc&rc...
Considering it already contains procedures for the behavior of breaking on
returns, it's probably the right place for such a change to be.

Additionally, this CR should probably have been related to bug 499287, not
495202.

[pfeldman, 2015-06-29 17:42:15]

> This prevents users from stepping between statements on a single line - a
useful
> feature to have when working with minified files, and something the debugger
> fully supports. It would be better that this is left unaltered

This adds confusion into the average case while trying to solve a not-so-average
case. One should not be debugging minified files without formatting them first.

> and the algorithm
> for selecting the 'closest' break location in v8 be changed to match the
desired
> behavior of selecting one statement earlier than currently is chosen with
> nonzero column numbers. It can be found here:
>
https://code.google.com/p/chromium/codesearch#chromium/src/v8/src/debug.cc&l=223
> and here
>
https://code.google.com/p/chromium/codesearch#chromium/src/v8/src/debug.cc&rc...
> Considering it already contains procedures for the behavior of breaking on
> returns, it's probably the right place for such a change to be.

It might still be worth addressing, but I don't see how we can provide the
feedback to the user wrt point we continue to. It could be an interactive tool
where you say "continue to location" and statement under cursor starts glowing,
then you move cursor over the desired location, it highlights and you confirm it
via click.

> 

> Additionally, this CR should probably have been related to bug 499287, not
> 495202.

Yes, my bad, closing the other one as dupe.

[wes, 2015-06-29 23:46:46]

On 2015/06/29 17:42:15, pfeldman wrote:
> It might still be worth addressing, but I don't see how we can provide the
> feedback to the user wrt point we continue to. It could be an interactive tool
> where you say "continue to location" and statement under cursor starts
glowing,
> then you move cursor over the desired location, it highlights and you confirm
it
> via click.

The devtools already highlight to indicate what has yet to execute on a line
when paused, 
so in that regard I think you're pretty good. Maybe simply changing the context
menu option from 'Continue to here' (which isn't necessarily true unless we turn
on
in-statement breakpoints) to 'Continue and break before statement' is
sufficient? 
(Though present behavior is 'break after statement') 'Continue and break before 
statement' is more truthful to the action and forthright with what will happen -
though a bit verbose.