[Webkit-unassigned] [Bug 37306] Web Inspector: Stop using JavaScript Script* objects as a transport for InspectorController <=> front-end interaction.

[bugzilla-daemon at webkit.org]

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





--- Comment #3 from Patrick Mueller <pmuellr at yahoo.com>  2010-04-09 07:26:21 PST ---
(In reply to comment #0)
> 1) InspectorController => front-end
> 
> Today we use JavaScript wrappers living in Script* for sending messages from
> InspectorController to the front-end.
> - This approach is straightforward for WebKit's in-process architecture
> - We've found a solution for Chromium that uses custom dispatch implementation
> and marshals the calls across the process boundary.
> 
> There are several drawbacks in this way of living:
> - Inspector is running its javascript code on the inspected page (this might
> affect profiling, debugging, prevents from instrumenting gc well)
> - This is hacky from the multiprocess point of view: it introduces artificial
> js environment.
> 
> The proposed solution is to use Chromium's value infrastructure instead of
> ScriptObject / ScriptArray / ScriptValue when talking to the front-end:
> - http://src.chromium.org/viewvc/chrome/trunk/src/base/values.h
> - http://src.chromium.org/viewvc/chrome/trunk/src/base/json/json_writer.cc
> - Replace WebInspector.dispatch's setTimeout with WebCore level async execution
> for in-process version of inspector + out-of-process versions of WebKit and
> Chromium will naturally provide that.

I don't see how Value helps at all with the drawbacks you mention.  Is the goal
to not have to run any JavaScript on the inspected page at all?  For some
areas, like DOM interaction, JavaScript seems like a great way to write the
code running on debug target; for other areas, like JavaScript debugging, it
makes no sense (there are no public JS debug APIs).

I'm not against using Value at all, it looks rather nice.  I just don't
understand how it addresses the drawbacks you mention.

It seems like using isolated worlds to implement things like the DOM
introspection kit running in the debug target would help with some of the
drawbacks you mention (allowing you to separate profiling/debug/gc/etc user
code from debug code accessing the same DOM).  I don't see "introduces
artificial js environment" as a big drawback :-)

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