Re: [Chrome DevTools] Contributing to Chrome Developer Tools

[Pavel Feldman]

Here is the way I do it when I don't want to deal with the official build procedure:

[SETUP]

1) check out WebKit sources from a fast git mirror for WebKit with full history

git clone http://git.chromium.org/external/Webkit.git WebKit

2) start local web server that would serve from inspector folder. Here is the nginx config fragment:

    server {

        listen       8090;

        server_name  localhost;

        location / {

            root                   /Users/pfeldman/WebKit/Source/WebCore/inspector;

            autoindex              on;

        }

    }

3) Download Chrome Canary https://tools.google.com/dlpage/chromesxs (preferred) or latest Chromium (http://commondatastorage.googleapis.com/chromium-browser-continuous/index.html)

[RUNNING]

1) Start Canary with the following command line flag:

/Applications/Google\ Chrome\ Canary.app/Contents/MacOS/Google\ Chrome\ Canary  --remote-debugging-port=9222 --remote-debugging-frontend="http://localhost:8090/front-end/inspector.html"

2) Open sample page (A) you want devtools to inspect

3) In your Chrome, open localhost:9222 and start remote debugging of (A)

4) Open DevTools for DevTools. Reload that page every time you apply changes to source code. Note that Cmd+R is overriden, so you need to reload using the button.

5) See http://trac.webkit.org/wiki/UsingGitWithWebKit on how to cook / upload patches

[John J Barton]

On Sat, Jun 16, 2012 at 2:51 PM, Nikita Vasilyev <m...@elv1s.ru> wrote:
> https://developers.google.com/chrome-developer-tools/docs/contributing does
> not describe how to make a patch out of changes and where to submit it.
>
> How do you develop DevTools? What’s your workflow?
>
> This is what I do:
> 1) Check out chromium
> (http://dev.chromium.org/developers/how-tos/get-the-code)
> 2) Download devtools_frontend.zip and `cp -r` its content to
> 'third_party/WebKit/Source/WebCore/inspector/front-end'

I gather that this step over-writes the current "trunk" source with
the content of a zip file. Where do you get that zip file and why to
you overwrite the source rather than opening the file on a temp
directory?

> 3) Download latest Chromium from
> http://commondatastorage.googleapis.com/chromium-browser-continuous/index.html
> 4) Run Chromium.app/Contents/MacOS/Chromium
> --debug-devtools-frontend=/Users/nv/Code/chromium/src/third_party/WebKit/Source/WebCore/inspector/front-end/
>
> Then I edit JS and CSS files in
> /Users/nv/Code/chromium/src/third_party/WebKit/Source/WebCore/inspector/front-end/,
> reload DevTools, edit, reload DevTools…
>
> Since third_party/WebKit/Source/WebCore/inspector/front-end/ is just a
> WebKit git repo, I can make a patch out of it by following
> http://trac.webkit.org/wiki/HackingWebInspector
>
> How do you do it?

I have a copy of the inspector/front-end files in a Chrome extension
called "sirius", under extension/atopwi/inspector/front-end:
https://github.com/johnjbarton/sirius
I launch the devtools front-end from the extension using a context
menu entry. This opens a new window running the prototype code; I open
normal devtools on that window.

I edit the files within devtools, and save back to the extension
source using Andrey K.'s devtools-save extension. Then I use shell
scripts to copy the files back to the chromium source tree to create
patches.

Sirius also copies other directories from WebKit:
LayoutTests/http/tests/inspector/
Source/WebCore/inspector/front-end/
LayoutTests/inspector/
Source/WebKit/chromium/src/js/
Eventually I hope to able to run the tests within Sirius.

My motivation for this unusual approach is to dogfood Sirius. Sirius
uses chrome.debugger to send debug commands to the back end and can be
used by eg Web IDEs to connect to the backend without command line
flags on the browser. I also hope to make the testing system more
usable and re-usable over time.

jjb

[Nikita Vasilyev]

Pavel, thanks for sharing, I’ll try to do it your way.

On Jun 18, 2012, at 9:44 PM, John J Barton wrote:

On Sat, Jun 16, 2012 at 2:51 PM, Nikita Vasilyev <m...@elv1s.ru> wrote:

https://developers.google.com/chrome-developer-tools/docs/contributing does

not describe how to make a patch out of changes and where to submit it.

How do you develop DevTools? What’s your workflow?

This is what I do:

1) Check out chromium

(http://dev.chromium.org/developers/how-tos/get-the-code)

2) Download devtools_frontend.zip and `cp -r` its content to

'third_party/WebKit/Source/WebCore/inspector/front-end'

I gather that this step over-writes the current "trunk" source with
the content of a zip file. Where do you get that zip file and why to
you overwrite the source rather than opening the file on a temp
directory?

https://developers.google.com/chrome-developer-tools/docs/contributing says:

Go to Chromium continuous builds archive and grab a recent revision of Chromium and the devtools_frontend.zip archive for it.

Actually, I copy only devTools.html, DevTools.js, and a few others that don’t present in the WebKit repo just to be able to run it with --debug-devtools-frontend. Otherwise it doesn’t work.

Editing files in a temp directory would require me to constantly copy files to WebKit repo.

I’ll give Sirius a try, thanks.

[Pavel Feldman]

> Doesn’t work for me. Chrome runs with the default DevTools totally ignoring
> the URL I pass to it. It doesn’t show any related errors:

That's expected. The custom DevTools will show up in step (3). Step
(4) is where you debug these custom DevTools using stable ones.

[Pavel Feldman]

That's because you are lucky :) Approximately twice a year we make incompatible changes that make newer front-end not work with the older Chrome during the load sequence. And you just hit the case. The zip method would also fail against the Canary in these cases. Just comment out that line and wait for the newer Canary. In reality, this almost never happens.

On Mon, Jun 25, 2012 at 7:27 AM, Nikita Vasilyev <m...@elv1s.ru> wrote:

Now I’m having the following error: 

 WebKit r121152, Canary 22.0.1186.0

[Pavel Feldman]

Hm. WebKit ToT does work for me against today's Canary 23.0.1270.0 (157306).