Bug 120334 - Web Inspector: Column Breakpoint not working, may be off by 1
Summary: Web Inspector: Column Breakpoint not working, may be off by 1
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Web Inspector (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Joseph Pecoraro
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2013-08-26 17:25 PDT by Joseph Pecoraro
Modified: 2013-08-27 07:12 PDT (History)
6 users (show)

See Also:


Attachments
[PATCH] Proposed Fix (6.56 KB, patch)
2013-08-26 20:26 PDT, Joseph Pecoraro
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Joseph Pecoraro 2013-08-26 17:25:22 PDT
* STEPS TO REPRODUCE
1. Inspect <http://bogojoker.com/shell/>
2. Set breakpoint on pretty printed easySlider.min.js line 19 "var options = …"
3. Reload the page
  => Expected breakpoint to be hit, it was not

* NOTES
• Frontend is setting a breakpoint on { lineNumber:1, columnNumber:274 }. However, it should probably be 275. I think 274 (one based) is a ";".
• I think this is what was causing issues with "Continue to here".
Comment 1 Radar WebKit Bug Importer 2013-08-26 17:25:31 PDT
<rdar://problem/14840678>
Comment 2 Joseph Pecoraro 2013-08-26 18:09:17 PDT
Nope, I take this back. This is a 0-based number, so the index is correct. In the line:

    "(function($){$.fn.easySlider=function(options){var defaults={prevId:'prevBtn',nextId:'nextBtn',prevText:'Previous',nextText:'Next',autogeneratePagination:false,orientation:'',speed:800,autoplayDuration:0,restartDuration:2500,loop:false,hoverPause:0,hover:false,easing:null};var options=…"

0-based index 274 is the "v" in "var options" as expected.

In ScriptDebugServer::hasBreakpoint I'm seeing line:1, column:275. Now to investigate why these disagree.
Comment 3 Joseph Pecoraro 2013-08-26 18:33:20 PDT
I think this is because JSC switched to 1 based column numbers and we're still assuming 0 based in ScriptDebugServer. For example:

    void ScriptDebugServer::updateCallFrameAndPauseIfNeeded(const DebuggerCallFrame& debuggerCallFrame, intptr_t sourceID, int lineNumber, int columnNumber)
    {
        ...
        TextPosition textPosition(OrdinalNumber::fromOneBasedInt(lineNumber), OrdinalNumber::fromZeroBasedInt(columnNumber));
        ...
    }

This does indeed look like it might be the problem. With a quick test script:

    var a=1;
     var b=2;
      var c=3;
       var d=a+b+c;
        console.log(d);
Comment 4 Joseph Pecoraro 2013-08-26 18:40:05 PDT
Yep, this fixes the issue. Now to write a test for this so it never regresses!
Comment 5 Joseph Pecoraro 2013-08-26 20:26:15 PDT
Created attachment 209709 [details]
[PATCH] Proposed Fix

Fix and test.

The reason that a lot of breakpoints were working currently was that if the breakpoint was set at the start of a line (column 0) we break anywhere on the line. That would be the case for non-pretty printed code, or setting a breakpoint on a line in pretty printed source that happened to be on the start of a line in the non-pretty-printed code.
Comment 6 David Kilzer (:ddkilzer) 2013-08-27 06:47:30 PDT
Comment on attachment 209709 [details]
[PATCH] Proposed Fix

r=me
Comment 7 WebKit Commit Bot 2013-08-27 07:12:28 PDT
Comment on attachment 209709 [details]
[PATCH] Proposed Fix

Clearing flags on attachment: 209709

Committed r154681: <http://trac.webkit.org/changeset/154681>
Comment 8 WebKit Commit Bot 2013-08-27 07:12:31 PDT
All reviewed patches have been landed.  Closing bug.