Issue metadata
Sign in to add a comment
|
DOMDebugger.setInstrumentationBreakpoint sends different Debugger.paused events than Chrome 68
Reported by
dig...@hotmail.com,
Sep 11
|
||||||||||||||||||||
Issue description
UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.106 Safari/537.36
Steps to reproduce the problem:
1. Set DOMDebugger.setInstrumentationBreakpoint
2. Load a web-page with a script which has a breakpoint on the first line of the script
3. In Chrome 69 we only get 4 Debugger.paused events
This is the 4th and last event:
← From chrome: {"method":"Debugger.paused","params":{"callFrames":[{"callFrameId":"{\"ordinal\":0,\"injectedScriptId\":2}","functionName":"","functionLocation":{"scriptId":"26","lineNumber":0,"columnNumber":0},"location":{"scriptId":"26","lineNumber":0,"columnNumber":0},"url":"http://localhost:55831/js/site.js?v=SShiBw-ynzPwRkh4xOIsqsXgTuI-6jwQqr5BhD0JEvU","scopeChain":[{"type":"global","object":{"type":"object","className":"Window","description":"Window","objectId":"{\"injectedScriptId\":2,\"id\":7}"}}],"this":{"type":"object","className":"Window","description":"Window","objectId":"{\"injectedScriptId\":2,\"id\":8}"}}],"reason":"EventListener","data":{"eventName":"instrumentation:scriptFirstStatement"},"hitBreakpoints":[]}}
What is the expected behavior?
In Chrome 68 after the 4th Debugger.paused event we also get a 5th Debugger.paused event:
← From chrome: {"method":"Debugger.paused","params":{"callFrames":[{"callFrameId":"{\"ordinal\":0,\"injectedScriptId\":2}","functionName":"","functionLocation":{"scriptId":"26","lineNumber":0,"columnNumber":0},"location":{"scriptId":"26","lineNumber":0,"columnNumber":8},"url":"http://localhost:55831/js/site.js?v=SShiBw-ynzPwRkh4xOIsqsXgTuI-6jwQqr5BhD0JEvU","scopeChain":[{"type":"global","object":{"type":"object","className":"Window","description":"Window","objectId":"{\"injectedScriptId\":2,\"id\":9}"}}],"this":{"type":"object","className":"Window","description":"Window","objectId":"{\"injectedScriptId\":2,\"id\":10}"}}],"reason":"other","hitBreakpoints":["2:0:8:[hH][tT][tT][pP]:\\/\\/[lL][oO][cC][aA][lL][hH][oO][sS][tT]:55831\\/[jJ][sS]\\/[sS][iI][tT][eE]\\.[jJ][sS]\\?[vV]=[sS][sS][hH][iI][bB][wW]-[yY][nN][zZ][pP][wW][rR][kK][hH]4[xX][oO][iI][sS][qQ][sS][xX][gG][tT][uU][iI]-6[jJ][wW][qQ][qQ][rR]5[bB][hH][dD]0[jJ][eE][vV][uU]"]}}
What went wrong?
This change in behavior broke some features of our debugger
Did this work before? Yes Chrome 68
Does this work in other browsers? N/A
Chrome version: 69.0.3497.81 Channel: stable
OS Version: 10.0
Flash Version:
,
Sep 12
digeff@ Thanks for the issue. Request you to provide a sample file where this issue can be reproduced, which will help in further triaging of the issue. Also a screen cast of the steps followed to reproduce the issue will be helpful in better understanding. Thanks..
,
Sep 12
I'm attaching a small VS Code sample that reproduces the issue. 1. host index.html in a web-server using http-server or something equivalent 2. Set breakpoints on line 1 and 2 of file.js 3. Launch the VS Code Chrome debugger and it'll hit line 2 instead of line 1 due to this issue
,
Sep 12
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Sep 12
This is the VS Code Chrome debug issue about this issue: https://github.com/Microsoft/vscode-chrome-debug/issues/729
,
Sep 13
digeff@, Thanks for the reply.Tried to tested this issue on Windows 10 using chrome reported version-69.0.3497.81 as per C#3.Able to set first 2 steps & not sure about 3rd step. Please find the attached screencast & it would be more helpful if you provide us screencast of the issue to triage from our end.
,
Sep 13
jmukthavaram@ VS Code has a feature to hit a breakpoint the first time you launch a web-page. Chrome Dev-tools work in a different way, so this feature doesn't make sense there, so they don't use the API we are using like that, so you won't run into that issue there. The way the feature works is that the user sets a breakpoint on C:\myproject\file.js. Then when the user starts debugging their project we launch chrome in about:blank, we enable the DOMDebugger.setInstrumentationBreakpoint API for script elements so it'll pause each time a script is about to be executed. When we hit the pause on localhost:1234/www/file.js that we get from DOMDebugger.setInstrumentationBreakpoint we figure out that localhost:1234/www/file.js and C:\myproject\file.js refers to the same "file" as far as the user is concerned, so we set the breakpoints that we had on C:\myproject\file.js on the URL localhost:1234/www/file.js, and then we resume and hit the breakpoints that we need to hit on: localhost:1234/www/file.js The change in behavior of DOMDebugger.setInstrumentationBreakpoint is breaking us because when we resume after setting the breakpoints on localhost:1234/www/file.js it's not hitting the first breakpoint on that file, but the second one. This issue only makes sense and can only be reproduced in VS Code.
,
Sep 13
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Sep 14
digeff@ Thanks for the update. As per comment #7, as this issue can be reproduced using VS code, this setup is not available at TE end to confirm the issue. Hence adding 'TE-NeedsTriageHelp' and requesting 'Blink>JavaScript' team to look into the issue and help in further triaging. Thanks..
,
Sep 20
,
Sep 28
|
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by krajshree@chromium.org
, Sep 12