[Webkit-unassigned] [Bug 35016] Enable alternate front-ends for Web Inspector

Wed Feb 17 13:08:11 PST 2010

https://bugs.webkit.org/show_bug.cgi?id=35016

--- Comment #12 from Jamey Hicks <jamey.hicks at nokia.com>  2010-02-17 13:08:10 PST ---
(In reply to comment #6)
> (In reply to comment #5)
> > Created an attachment (id=48913)
 --> (https://bugs.webkit.org/attachment.cgi?id=48913) [details] [details]
> > Qt debug agent partially implementing ChromeDevTools and V8 debug protocol
> > 
> > For reference: This is a patch to Qt that implements remote Web Inspector
> > usage, supporting all Web Inspector functionality. It is a quick prototype and
> > not stable.
> > 
> > It includes an HTTP server in QWebInspector that can be enabled for remote
> > debug. It serves 4 information channels through the HTTP server:
> > 1) Built-in resource files -- the HTML, Javascript, images, and style sheets
> > composing the Web Inspector UI (original encoding)
> 
> Ok.
> 
> > 2) Asynchronous RPC to InspectorBackend via HTTP POST (encoded as JSON)
> 
> How do you deal with the calls to the InspectorFrontendHost? They are supposed
> to be served on the front-end side. Are you sending those to the inspected page
> side as well?

Qt 4.6 uses an older version of WebKit that does not yet have
InspectorFrontendHost, so I did not encounter this problem. I do not have a
solution for this problem, but InspectorFrontendHost should be in the
process/page of the UI, not the backend.

> 
> > 3) Polling for events to the frontend via HTTP POST (encoded as JSON)
> 
> Polling is not good - couldn't we just leave connection open and push client
> dispatches in the <script> tags?

That would be an improvement. I am still learning how to do some of these
things in Javascript. In my prototype, I believe it delivers all the items that
are in the InspectorRemoteFrontend's queue each time a POST is handled, and it
keeps a POST open until there is some data. I'm sure a slight tweak would allow
that connection to be kept open for the duration of the debug session.

> > 4) Dynamic resources via HTTP POST (to fetch these resources from the same
> > context as the browser, in original encoding)
> > 
> 
> Could you explain what this is about?

Currently, the Web Inspector UI fetches resources in its own page context when
the user wants to see them. If those were local file URLs, for example, and the
UI is running on a different device, then it cannot fetch them. This interface
enables the UI to fetch resources in same context as the inspected page so that
it gets the same thing the inspected page would get. This was a tiny change to
the UI.

> > The Inspector front-end javascript is modified to use asynchronous style when
> > communicating with the back-end.
> > 
> 
> It took us a while (half a year of so) to re-implement entire front-end in
> order to serialize communication and make it asynchronous. What did you find
> missing? The only thing I can remember of is debuggerEnabled / profilerEnabled
> calls (we did not need these in Chromium). I had a pending change for that.
> Anyways, I can't see your changes in the patch.

I'm pretty sure that some of the changes I made here were not needed, but I did
not understand the code before I started. However, there were some calls to
WebInspector.InspectorController methods that were expecting to be synchronous.
Again, this is using an older webkit snapshot.

> > In my current design, the remote debug agent would not require instantiating
> > the Page for the Web Inspector UI nor would it require QWebInspector.
> > 
> 
> Yury is currently working on a change that would abstract creation of the
> inspector UI page via the InspectorClient interface. InspectorController will
> basically be asking for host to open inspector somewhere and will wait while
> this new front-end connects to it. Any external client (non-standard frontend)
> should also be able to connect using new API. It will be a modified version of
> setFrontendProxyObject.
> 
> > In terms of implementation, it was very quick because it does not change the
> > messages or encodings between the backend and UI, though use of XMLHttpRequest
> > caused a change to an asynchronous style of communication.
> 
> Where is this code located?

In patch 48913, webkit is in src/3rdparty/webkit and the debug server is in
src/3rdparty/webkit/WebKit/qt/WebCoreSupport. It is just a proof of concept.

> 
> General notes:
> - It would be interesting to see the server implementation and the front-end
> code. It is important to remember that inspector controller does not expose its
> protocol and that InspectorFrontend / InspectorBackend interfaces are private
> to WebCore (should not be accessed from within WebKit).

In that case, I think we need to develop a stable inspector backend interface
to be exported from WebCore.

> - Talking about supporting V8 protocol over InspectorBackend, it is something
> quite opposite from what we were thinking about. Instead, we were going to
> establish a scope-alike protocol in the WebKit first, let it mature and move
> Eclipse debugger to it.

Sounds OK to me. The V8 debugger protocol is clearly V8 specific. It would be
nice to have a more neutral protocol.

> - Eclipse ChromeDevTools / Chromium do not maintain debugging API in terms of
> protocol, they provide the support in terms of the SDK instead. Every new
> version of Chromium has an SDK update in case of breaking changes to the
> protocol. Your implementation is clearly not ready for that.

Agreed. My implementation is just a starting point for discussion about what
interfaces are needed and what the information flows are across those
interfaces.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.