Add support for debug-brk/inspect-brk flags (Break on load)
Reported by
kenn...@auchenberg.dk,
Jul 26 2017
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36 Steps to reproduce the problem: In VS Code we have several users who are confused about the lack "break on load" which requires our users to refresh their page in Chrome before breakpoints are hit in our Chrome debugger. Details: https://github.com/Microsoft/vscode-chrome-debug/issues/445 What is the expected behavior? It would be great if Chrome gained launch flags similar to Node's debug-brk/inspect-br that breaks execution on first line. This could enable external debuggers to be able to set breakpoints in immediate running code and continue execution afterwards. What went wrong? See above. Did this work before? N/A Chrome version: 59.0.3071.115 Channel: n/a OS Version: OS X 10.12.4 Flash Version:
,
Jul 27 2017
Note that external debugger can launch chrome with about:blank, attach, setBreakpointByUrl and then navigate to the page. Does that work for you?
,
Jul 27 2017
Just spoke with one of our engineers, and he said that we in some cases for Visual Studio (not Code) don't know the urls ahead of the page load, which causes problems for us today, where open Chrome, open a interstitial, set breakpoints and then redirects to the target url. I wonder if breaking on first line will be enough, as that will script execution and stop the flow of Debugger.scriptParsed events too right?
,
Jul 27 2017
Thank you for providing more feedback. Adding requester "dgozman@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jul 31 2017
,
Jul 31 2017
There are two methods to stop at right place: - "Debugger.pause" stops at nearest JS execution. This may be racy if navigation is happening in parallel. - "DOMDebugger.setInstrumentationBreakpoint" with "scriptFirstStatement" eventName. This should pause on first line of any script execution. I think any of them should work for you, but second one is very similar to proposed "debug-brk" behavior. > I wonder if breaking on first line will be enough, as that will script execution and stop the flow of Debugger.scriptParsed events too right? Yes, pausing JS execution should be enough to stop most scriptParsed events (apart from internal ones maybe). Please file issues about protocol details here: https://github.com/ChromeDevTools/devtools-protocol, for better visibility. I will be happy to continue discussion there. Closing this bug for now.
,
Jul 31 2017
Thanks @dgozman! I wasn't aware of DOMDebugger.setInstrumentationBreakpoint. I think this will enable us to move forward, but we still have the very problem of JS execution being paused, which stops the flow of scriptParsed events. We need the events to map the loaded scripts to the local file system, as we not always can know the script urls ahead of time (Ex: webpack-dev-server serves virtual files, which we can't predict the url of) I'll open a new issue. |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by nyerramilli@chromium.org
, Jul 27 2017