In the light of WebKit2, we can start _now_. 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. 2) front-end => InspectorController Today, we inject InspectorBackend binding into the front-end in WebKit / inject it into utility context on the inspected page side in Chromium. Time to align in the light of WebKit2 changes. What we should do is: - Provide a way of marshaling InspectorBackend.* calls from the front-end to the InspectorController across process boundary. InspectorBackend.* are only operating primitive parameter types, are called from JavaScript environment and should be dispatched on a native object. There is no strict need for it to be a binding anymore should we come up with a cross-process binding that supports primitive value types. Two ways of solving: - Based on the IDL, generate a dispatcher that would parse call payloads and dispatch them on InspectorBackend native instance Pros: Code gen approach Cons: People might consider all idls are bindings, code gen is in perl - Move from the IDL to a Chromium-style macro Pros: We have some code to reuse Cons: Macros are bad comparing to the code gen.
> - Move from the IDL to a Chromium-style macro > Pros: We have some code to reuse > Cons: Macros are bad comparing to the code gen. Why not use CoreIPC instead. This scenario should fit fine into that framework. Also if we decide to stick to Chromium's value infrastructure in case of InspectorController => front-end it would make sense to use that infrastructure for the opposite direction so that we could define an API based on the "value" types.
(In reply to comment #1) > ... it would make sense to use that infrastructure > for the opposite direction so that we could define an API based on the "value" > types. In general, it would be nice to have "both directions" use the same style. It seems like it would be nice to chunk the "APIs" into areas: resources, javascript debugging, javascript profiling, DOM, etc. For example, if we go an IDL route, we'd have separate interfaces for each of those areas.
(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 :-)
> 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). > Nope, this is not related to the injected scripts and running js in the inspected page. It is about not using inspected page javascript engine for the transport. > 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). Although unrelated to this bug, you can't use isolated world for inspecting dom - you want to inspect dom wrapper properties belonging to the main world. > I don't see "introduces > artificial js environment" as a big drawback :-) That's because you don't have to maintain page inspection within existing and improving security constraints. Calling js between contexts is considered harmful.
(In reply to comment #4) > Although unrelated to this bug, you can't use isolated world for inspecting dom > - you want to inspect dom wrapper properties belonging to the main world. Ah yes. Though of course you can introspect over the DOM, just can't see anything the main world tacked on to it. Of course we need to see those bits the main world tacked on for Web Inspector. Of course, there are layers here. For initial element tree population, for example, you can get by with stuff that's is available to the isolated world. A better example would be DOMStorage, which you could presumably access via an isolated world. A trivial amount of diagnostic information on app-cache (ie, the current public API on app-cache) would also likely be obtainable via an isolated world. > > I don't see "introduces > > artificial js environment" as a big drawback :-) > > That's because you don't have to maintain page inspection within existing and > improving security constraints. Calling js between contexts is considered > harmful. Which is why isolated worlds are so great. The whole reason I'm bringing this up is that I'd like to see as much of Web Inspector written in JS as is possible/reasonable. Like it is today, only more. Not less. It's not clear to me whether this bug affects that or not, and if it does, affects it negatively (more C++ code) or positively (more JS code).
> A better example would be DOMStorage, which you could presumably access via an > isolated world. A trivial amount of diagnostic information on app-cache (ie, > the current public API on app-cache) would also likely be obtainable via an > isolated world. > We try to avoid using isolated worlds since they require management and eat heap. Management part turned out to be inevitable, but the memory one we could save by means of injected script that we anyway need for main world inspection. > The whole reason I'm bringing this up is that I'd like to see as much of Web > Inspector written in JS as is possible/reasonable. Like it is today, only > more. Not less. It's not clear to me whether this bug affects that or not, > and if it does, affects it negatively (more C++ code) or positively (more JS > code). I agree with the general idea. Unfortunately, it is not always possible. Like for styles inspection of iframes loaded cross domain, we needed to move to native. Creating node wrappers can also be expensive and affect GC, etc. So yes, we are for simplicity, but we are first of all for accuracy.
*** Bug 67305 has been marked as a duplicate of this bug. ***