Enable remote-debugging server via SIGUSR1 signal to running process
Reported by
kenn...@auchenberg.dk,
Sep 23 2016
|
||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.116 Safari/537.36 Steps to reproduce the problem: External tools like VS Code that wants to debug Chrome needs to kill existing Chrome processes and re-launch Chrome with the --remote-debugging-port flag in order to start the remote debugging to allow external connections. This gives a cumbersome user experience for most developers. What is the expected behavior? The proposal is to add listener for a SIGUSR1-signal, which should start the remote debugging server within the existing process, and return the available port. This would enable tools like VS Code, to enumerate running Chrome processes and send the SIGUSR1 when remote debugging is needed. If this is a security concern, a flag could be enabled by a Chrome Extension to enable this functionality. Similar functionality are expected to land for Node's new v8_inspector. See https://github.com/nodejs/node/issues/8464 What went wrong? Nothing. Did this work before? N/A Chrome version: 53.0.2785.116 Channel: stable OS Version: OS X 10.12.0 Flash Version: Shockwave Flash 23.0 r0
,
Apr 12 2017
Our team had considered this in the past - but it does not seem to be a feasible model for a Chrome browser. Chrome browser is multi-process (unlike Node.js that is single-process). Also, signals are not available on Windows (e.g. Node has a very different implementation on Windows that requires starting a second instance of the Node.js).
,
Apr 14 2017
Closing as a different solution is needed. |
||
►
Sign in to add a comment |
||
Comment 1 by paulir...@chromium.org
, Oct 10 2016Owner: eostroukhov@chromium.org
Status: Assigned (was: Unconfirmed)