Bug 75973
| Summary: | Web Inspector: DOMAgent.getDocument should take an optional frameId argument | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Timothy Hatcher <timothy> |
| Component: | Web Inspector | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED INVALID | ||
| Severity: | Normal | CC: | apavlov, bburg, bweinstein, inspector-bugzilla-changes, keishi, loislo, pfeldman, pmuellr, rik, webkit-bug-importer, yurys |
| Priority: | P2 | Keywords: | InRadar |
| Version: | 528+ (Nightly build) | ||
| Hardware: | All | ||
| OS: | All | ||
Timothy Hatcher
I would like to get the document for a specific frame. It seems logical that DOMAgent.getDocument could take a frameId to get a specific frame. If it isn't included it would be the main frame document like it is today.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Pavel Feldman
As of today, DOM agent is combining all of the frames into a single node hierarchy. I.e. frame owner element returns corresponding document's children as its own:
<iframe>
<html>
</html>
</iframe>
Historical reasons, the protocol was derived from the working implementation where all trees were combined into one. Not only it builds a single hierarchy, it also filters out intermediate nodes that correspond to #document DOM node.
I was thinking of refactoring it multiple times, but there were two things preventing me from doing so:
1. It is a fairly large effort
2. It puts more pressure on the front-end implementor that would need to manage multiple model trees in a single UI tree representation.
Now that I am working on the free flow DOM editing, I need a better mapping between resources and documents. So chances are high I'll need to complete this task this time.
As for the frameId, we already use it in the Page and Network domains. We just need to make it explicit and expose the frame hierarchy in the protocol.
Timothy Hatcher
I don't think the combined tree needs to change. We would need to include the document nodes under frames (so iframe -> document -> html). If you ask for a document for a subframe you get that whole subtree. The UI would just know to skip the document node when expanding a subframe.
That, IMHO, would be the simplisest way to do this.
Pavel Feldman
(In reply to comment #2)
> I don't think the combined tree needs to change. We would need to include the document nodes under frames (so iframe -> document -> html).
That is in my immediate plans.
If you ask for a document for a subframe you get that whole subtree. The UI would just know to skip the document node when expanding a subframe.
>
> That, IMHO, would be the simplisest way to do this.
What is your user scenario then? Note that DOMAgent.getDocument is unique in a sense that it returns the node. All other methods are requesting that nodes are pushed to the client (requestChildNodes, etc.). Backend will not send the node to the front-end if it knows front-end already has it. So requirement for DOMAgent.getDocument(frameId) to work is equivalent to splitting the document in my mind.
I suspect there is a workaround for what you need without involving frame id:
RuntimeAgent.evaluate("frames[1].document", function(error, result) {
DOMAgent.requestNode(result, function(error, nodeId) {
var node = WebInspector.domAgent.nodeForId(nodeId);
});
});
I.e. you get a javascript wrapper for the node you need and then convert it into the DOM terms.
Timothy Hatcher
I was just experimenting and found DOMAgent.getDocument lacking if I only care about a sub frame. Consider an WebView like Safari's Snippet Editor that has an editor and a preview view in one WebVIew. The user inspecting only cares about the content of the preview frame.
Your likely right, using RuntimeAgent.evaluate might work. Could I use the frameId parameter on RuntimeAgent.evaluate to evaluate "document" and convert that to a node?
How does the DOMAgent handle that if the child nodes have two parentNodes (document or the iframe element)?
Pavel Feldman
(In reply to comment #4)
> I was just experimenting and found DOMAgent.getDocument lacking if I only care about a sub frame. Consider an WebView like Safari's Snippet Editor that has an editor and a preview view in one WebVIew. The user inspecting only cares about the content of the preview frame.
>
To support this complete story, we need to maintain dom agent instance per document (both on backend and front-end sides). And that implies the complexities I was mentioning above. If you put a copy of the inspector into such a WebView and allow one such WebView to exist for page at a time, things would work out of the box.
> Your likely right, using RuntimeAgent.evaluate might work. Could I use the frameId parameter on RuntimeAgent.evaluate to evaluate "document" and convert that to a node?
I would think so.
> How does the DOMAgent handle that if the child nodes have two parentNodes (document or the iframe element)?
As of today, children of the <iframe> (document owner element) are its #document children. Parens of them are <iframe> element. See innerChildNode / innerParent code in InspectorDOMAgent.
Whatever you are doing, please consider upstreaming it to the WebKit. We are currently working on more editing capabilities, new scripts layout, etc. Would be great if what you do could fit the overall Web Inspector story.
Timothy Hatcher
Nothing to upstream at the moment, just random experiments at this point.
Radar WebKit Bug Importer
<rdar://problem/19281455>
Blaze Burg
Not sure this is needed any more. IIRC we have a helper to do the trick in #c3.