New issue
Advanced search Search tips

Issue 818142 link

Starred by 2 users

Issue metadata

Status: Available
Owner: ----
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Feature



Sign in to add a comment

Add support for --custom-devtools-frontend flag

Project Member Reported by skyos...@chromium.org, Mar 2 2018

Issue description

Labels: Hotlist-GoodFirstBug
I'd be interested in picking this up
So, looking into this, that code path is actually never hit. The headless_devtools_manager_delegate is configured to return that it serves bundled resources:

https://cs.chromium.org/chromium/src/headless/lib/browser/headless_devtools_manager_delegate.cc?l=417

This then impacts the JSON returned from /json/list. The problem is that no clients actually seem to end up respecting that. If you're inspecting from another browser, it will just use the websocket URL and it's own devtools.

I think the best solution here is to modify the devtools discovery page that headless returns. Currently, it ignores the frontend URL and will generate a 
http://chrome-devtools-frontend.appspot.com/ URL. I think that the correct behavior should be to use the actual devtools url returned by /json/list.

Do you think that is the right approach here? That would allow a headless user to inspect changes they've made locally to devtools, but wouldn't allow them to specify a front-end hosted elsewhere.

The problem with supporting this flag directly is that the URL is generated by the discovery HTML page which is a static resource. Without turning it into a template I don't think we can plumb the value of a flag into it.
Looking at the blame for the discovery URL, it looks like the reason the remote devtools is used is because the bundled version doesn't support the screencast feature (tangentially, I'm curious why that is).

So, the way I see it there are 2 things we could do here:

1. Turn the discovery HTML into a template which will respect and plumb through the data for --custom-devtools-frontend
2. Modify the headless_devtools_manager_delegate to return "false" when asked if it should use bundled devtools (or do so conditionally behind a flag --headless-use-bundled-devtools)

I think that 2 is really worth doing because it would allow us to get rid of the hack in discovery HTML which rewrites the bundled front-end URL as a remote URL. As far as I can tell, it is just duplicated code which could more easily be controlled by HasBundledFrontendResources().

https://cs.chromium.org/chromium/src/headless/lib/resources/devtools_discovery_page.html?l=26
https://cs.chromium.org/chromium/src/headless/lib/browser/headless_devtools_manager_delegate.cc?l=417
https://cs.chromium.org/chromium/src/content/browser/devtools/devtools_http_handler.cc?rcl=48526a7be16f327957576b7ecc38668d77ae32c9&l=476
I believe the remote screencast feature lets you see a live screenshot of the rendered page in the inspector. If switching to #2 doesn't break that, I think it would be fine to do that. However I haven't actually verified that we do bundle all of DevTools in headless mode.

Sign in to add a comment