Bug 120334 – Web Inspector: Column Breakpoint not working, may be off by 1

• Status: RESOLVED
• Resolution: FIXED
• Component: Web Inspector

[Joseph Pecoraro]

* 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".

[Radar WebKit Bug Importer]

<rdar://problem/14840678>

[Joseph Pecoraro]

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.

[Joseph Pecoraro]

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);

[Joseph Pecoraro]

Yep, this fixes the issue. Now to write a test for this so it never regresses!

[Joseph Pecoraro]

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.

[David Kilzer (:ddkilzer)]

Comment on attachment 209709 [details]
[PATCH] Proposed Fix

r=me

[WebKit Commit Bot]

Comment on attachment 209709 [details]
[PATCH] Proposed Fix

Clearing flags on attachment: 209709

Committed r154681: <http://trac.webkit.org/changeset/154681>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.