-
Notifications
You must be signed in to change notification settings - Fork 762
Investigate connecting to Chrome #49
Comments
I don't think we're going to get to this into Sprint 3, might want to leave it for the next sprint. |
agreed. |
Here's what I've learned so far experimenting with running inside Chrome. Chrome ExtensionChrome allows for most of the pieces we need but ultimately prevents us from running as a real debugger within a devtools panel. Chrome allows for extensions to access the Chrome RDP via an API: https://developer.chrome.com/extensions/debugger and it also allows for us to create our own panels https://developer.chrome.com/extensions/devtools_panels However it does not allow for an extension to attach the debugger to a tab which has the developer tools open. Meaning we can't have a competing debugger running in a panel within the developer tools; their debugger always wins. Therefore if we want to remain an extension we need to find another way to present our debugger to Chrome users that doesn't require their devtools to be open. I'm not sure that we want to remain an extension given this limitation but here are some ideas for how we could do this. Alternate extension approachesOne major limitation to keep in mind with any extension approach is that if the user opens the existing developer tools at anytime, our connection to the debugger will be terminated. Our extension will receive a notification about the termination however there is nothing we can do to reconnect until the developer tools are closed again by the user. i.e. we'll have to put up a notice saying "Please close the Chrome devtools to continue" Separate WindowAs an extension we could offer a toolbar button that opens a new window with our tools in it, from this window we could offer the list of tabs in the browser and attach to any available tab which doesn't already have a debugger attached to it. Separate PanelVery similar to the window approach we could create a different window type, called a panel which would eliminate most of the window chrome making us look more native. Its available from the Chrome Window API : WindowType However this approach requires our users to turn on a flag in the chrome://flags/#enable-panels page. Separate AppThe advantages of being an extension, ease of installation and devtools panel, don't see to outweigh the disadvantages we are facing in terms of not being able to run our debugger inside a devtools panel. I'd recommend looking at running our debugger as a separate application that connects to Chrome remotely. Much like the VS Code Debugger we'll need to spend time making sure people have opened Chrome with the correct command line flags but once they are connected we could possibly offer them a much more compelling experience than what is available via an extension. There could be hybrid approach where we offer a helper extension that opens our separate app and lets you know what tabs our app is connected to. The extension avenue isn't a total waste, just not a good one right now. |
Thanks Bryan for investigating. |
after investigating there will be a couple breakdown tasks
|
here's the work for updating tab ids and debugTab jlongster@c0f2ddb here's the commit for adding scriptParsed: jlongster@7f9b2fa |
done. If we want to do more work connecting to chrome we can open a new ticket |
Investigate a demo of debugger.html connecting to Chrome over the Chrome remote debug protocol (RDP). This investigation should also include best target platforms for delivering the Chrome debugger which may be Chrome itself or alternate platforms such as Electron.
The text was updated successfully, but these errors were encountered: