Adding 'Needs-Milestone' label, TE will check the issue and update the bug with comments & tag with respective Mstone

williamhowley@ - Thanks for filing this issue...!!

Could you please provide a sample URL to test this issue.

This will help us in triaging the issue further.

Thanks...!!

Setup was local. I know in typescript, you are not able to inspect async
functions but this was a normal one. I'm not sure how you guys would debug
this :/ if I see it again I'll try and find more info on it.

Thank you for providing more feedback. Adding requester "krajshree@chromium.org" for another review and adding "Needs-Review" label for tracking.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Reporter@ could you please provide a sample URL to test the issue.
It would help us in triaging the issue further.

Thanks..

Could be a source mapping issue. Could you please provide a source map file?

I'm not sure about this exact issue, but I have to say setting breakpoints now is a very random thing. some lines don't accept breakpoints (and they are not empty or var definitions etc.), sometimes they jump (one line, end of file or function), sometimes they are hidden (they break but no stars visible)
and now with 57 on mac they are shifted (the yellow marker is in the correct line but it looks like the previous line is the currently executing one)

I know I need to break this into different issues with more details but I just wanted to give feedback for the past months of using breakpoints (with and without source maps).


I just want a yellow marker where i click, nothing more, nothing less!
if I can't break on a line, gray it out and that's it.

I hope someone out there can make breakpoints great again :D

I have more information on this, or at least something similar. Consider the following Typescript program.

class Thing {
    key: Object;
}

class SomeClass {
    renderValue(value) { return value.hashCode.toString(); };

    onDestroy() {
        console.log('destroyed');
    }
}

Compile and serve this with sourcemaps and attempt to set a breakpoint on renderValue. It ends up setting it on the code line in onDestroy.

This is specific to the function being on a single line. What happens is that it ends up calling into uiLocationToRawLocation and that calls firstSourceLineMapping, passing only the line number. As a result it finds the first possible breakpoint on the line, which is the beginning of the function, and (hand-waving) the agent doesn't like that position and picks something else. Here's the stack trace getting to uiLocationToRawLocation, from Chrome 57.0.2987.133 on Mac.

uiLocationToRawLocation (inspector.js:formatted:36950)
_uiLocationToRawLocation (inspector.js:formatted:37968)
uiLocationToRawLocation (inspector.js:formatted:37843)
normalizeUILocation (inspector.js:formatted:37858)
setBreakpoint (inspector.js:formatted:38204)
_setBreakpoint (sources_module.js:532)
setBreakpoint (sources_module.js:527)
Promise.resolve (async)
checkNextLineIfNeeded (sources_module.js:524)
Promise.resolve (async)
checkErrorAndReturn (inspector.js:formatted:28033)
callback (inspector.js:formatted:19839)
dispatchResponse (inspector.js:formatted:19862)
_onMessage (inspector.js:formatted:19686)
_dispatchMessage (inspector.js:formatted:23134)
dispatchEventToListeners (inspector.js:formatted:5433)
innerDispatch (inspector.js:formatted:8260)
_dispatch (inspector.js:formatted:8256)
_dispatchOnInspectorFrontendAPI (devtools_compatibility.js:57)
dispatchMessage (devtools_compatibility.js:133)
(anonymous) (VM250:1)

I should add that I think this may be due to changes introduced in https://codereview.chromium.org/2484283004 , at least it's the thing that seems to have introduced some of the relevant code.

I also note that this is a regression, since the example works fine in Chromium 45.0.2454.104, which I happen to have handy.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/4b215935dccf392557df907d8eb68f06edc1a227

commit 4b215935dccf392557df907d8eb68f06edc1a227
Author: Alexey Kozyatinskiy <kozyatinskiy@chromium.org>
Date: Thu Oct 12 06:26:32 2017

[DevTools] use end line position to request possible breakpoints

Currently we use first char in next line, it regressed breakpoints in
files from source map.

TBR=lushnikov@chromium.org

Bug:  chromium:676388 , chromium:760229 , chromium:761263 
Change-Id: I10e83ff96fcda6aae77515003ae1d0cdf993ee84
Reviewed-on: https://chromium-review.googlesource.com/714436
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#508267}
[add] https://crrev.com/4b215935dccf392557df907d8eb68f06edc1a227/third_party/WebKit/LayoutTests/http/tests/devtools/sources/debugger-breakpoints/breakpoint-with-sourcemap-expected.txt
[add] https://crrev.com/4b215935dccf392557df907d8eb68f06edc1a227/third_party/WebKit/LayoutTests/http/tests/devtools/sources/debugger-breakpoints/breakpoint-with-sourcemap.js
[modify] https://crrev.com/4b215935dccf392557df907d8eb68f06edc1a227/third_party/WebKit/Source/devtools/front_end/sources/JavaScriptSourceFrame.js

I hope thins one will be fixed in next Canary release. Feel free to reopen it if it's still an issue.