Remote inspector extensions?

106 views
Skip to first unread message

Thomas Aylott

unread,
May 4, 2012, 6:10:31 PM5/4/12
to google-chrome-...@googlegroups.com
Ahoy,
Is there currently any plan to support frontend devtools extensions in the remote web inspector?
I'd like to build some extensions for use in Chrome that also work when inspecting a remote browser over a web socket connection.

Thanks much

John J Barton

unread,
May 9, 2012, 12:11:54 PM5/9/12
to Thomas Aylott, google-chrome-...@googlegroups.com
On Fri, May 4, 2012 at 3:10 PM, Thomas Aylott <tho...@subtlegradient.com> wrote:
> Ahoy,
> Is there currently any plan to support frontend devtools extensions in the
> remote web inspector?

Can you explain a bit more or point to a page describing the setup you
are using? There are a lot of ways to use the front-end.

In particular, the front end is usually running in a separate process
and by default it uses websockets to port 9222. So in normal operation
it is 'remote' to the backend, though it is running on the same
localhost.

> I'd like to build some extensions for use in Chrome that also work when
> inspecting a remote browser over a web socket connection.

It should be possible to have devtools extensions work where devtools
work except that devtools extensions can communicate with chrome
extension background pages.

And in any scenario where the devtools front-end is running in a
modern version of Chrome, you can use the front end embedded in an
extension and thus use the full API. However, if you are truly on a
different machine then the extension API won't be available.

jjb


>
> Thanks much

Thomas Aylott

unread,
May 9, 2012, 5:04:20 PM5/9/12
to google-chrome-...@googlegroups.com, Thomas Aylott
I have a separate machine running a browser that has remote debugging enabled and available over the LAN.
It serves its own version of the devtools_frontend, but I'm not using them.
Separately, I am serving my own version of the devtools_frontend locally. I then load the local frontend using the querystring ?ws=$TARGET_WS_URL.

So, it's trivial for me to hack up the source code in the devtools_frontend, but I don't want to have to maintain a lot of my own local changes to the devtools themselves.
What I'll probly do is create my own devtools.html file that loads resources from devtools_frontend in addition to my own extensions.

Ideally, I'd like my custom extensions to be able to be used in Chrome Extensions also, so I don't want to rely on the private implementation details of the devtools_frontend.
It'd be fine to have to use an API or shim or something that could map both environments to a single unified API. Ideally that wouldn't be necessary.

Andrey Kosyakov

unread,
May 10, 2012, 3:30:33 AM5/10/12
to Thomas Aylott, google-chrome-...@googlegroups.com
Hi Thomas,

On Sat, May 5, 2012 at 2:10 AM, Thomas Aylott <tho...@subtlegradient.com> wrote:
Is there currently any plan to support frontend devtools extensions in the remote web inspector?
I'd like to build some extensions for use in Chrome that also work when inspecting a remote browser over a web socket connection.


We do not officially _support_ this, but technically it's possible -- it's a crude hack, though, and may be broken at any moment, so use at your own risk.
Remote front-end is essentially a web application that the browser can't differentiate from others, so we can't rely on the browser to inject any special APIs into remote front-end. You can do that from an extension, though, provided that your extension knows the front-end URL. Here's the outline of what you need to do:

1. Inject the content script into devtools front-end (e.g. by "content_scripts" field in the manifest or via chrome.tabs.executeScript());
2. The content script injected at (1) should append a <script> element to document.body, so that the script within the element gets evaluated on the main world of DevTools front-end;
3. The script appended at (2) should call window.addExtension() method of the front-end with the full URL of your extension's devtools_page (i.e. the page you'd normally put into "devtools_page" field of the manifest);
4. The pages of your extension that run within the devtools context (i.e. the one you specify in (3) and those you create as panels/sidebars) need to explicitly include the API stub script from the server. Replace devtools.html with devtools_extension_api.js to get the URL of the extension API; you may either hard-code it or pass the devtools URL from within the script running in the main world of devtools (see step 3) via a query string of the devtools page URL;
5. Examples are intentionally missing. We don't officially support this and we want people to understand well what they are doing :) There are some examples of remote devtools extension in the wild, though -- Page Speed is one, I think.

Best regards,
Andrey.

Reply all
Reply to author
Forward
0 new messages