[HTMLTemplateElement] Allow <template> content to be inspected

[Rafael Weinstein]

<template> should be expandable in the 'elements' tab and it should contain a single '#document-fragment' child whose children are expandable.

[Rafael Weinstein]

Created attachment 180901 [details]
Patch

[Rafael Weinstein]

Here is the start of a patch for this. The main problem is that when anything in the templateContent changes, it is not updated in the UI.

I believe this is because there isn't an associated instrumenting agent with the owner document of the content or its children.

Pavel, a little background: The template element's content document fragment is "inert" (images don't load, script doesn't run, etc...). The way this is accomplished is that it is owned by a different document which doesn't have a browsing context (frame).

Unfortunately. this means that instrumentingAgentsForDocument() currently always returns 0;

What's the best way to approach this?

[Early Warning System Bot]

Comment on attachment 180901 [details]
Patch

Attachment 180901 [details] did not pass qt-ews (qt):
Output: http://queues.webkit.org/results/15549924

[Early Warning System Bot]

Comment on attachment 180901 [details]
Patch

Attachment 180901 [details] did not pass qt-wk2-ews (qt):
Output: http://queues.webkit.org/results/15559831

[EFL EWS Bot]

Comment on attachment 180901 [details]
Patch

Attachment 180901 [details] did not pass efl-ews (efl):
Output: http://queues.webkit.org/results/15587019

[Build Bot]

Comment on attachment 180901 [details]
Patch

Attachment 180901 [details] did not pass mac-ews (mac):
Output: http://queues.webkit.org/results/15550992

[Pavel Feldman]

Comment on attachment 180901 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=180901&action=review

> Source/WebCore/inspector/InspectorDOMAgent.cpp:1300
> +        if (element->hasTagName(HTMLNames::templateTag))

#if ENABLE(TEMPLATE_ELEMENT)

> Source/WebCore/inspector/front-end/DOMAgent.js:78
> +    if (payload.templateContent) {

No need for {} around one line block.

[Pavel Feldman]

> Pavel, a little background: The template element's content document fragment is "inert" (images don't load, script doesn't run, etc...). The way this is accomplished is that it is owned by a different document which doesn't have a browsing context (frame).



> 
> Unfortunately. this means that instrumentingAgentsForDocument() currently always returns 0;
> 
> What's the best way to approach this?

Could we do something like

m_templateContentsOwnerDocument->setTemplateContentsOwnerDocumentParent(this);

in modify Document::templateContentsOwnerDocument()?

Then instrumentingAgentsForDocument would follow that link and fetch appropriate page.

[Rafael Weinstein]

Comment on attachment 180901 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=180901&action=review

>> Source/WebCore/inspector/InspectorDOMAgent.cpp:1300
>> +        if (element->hasTagName(HTMLNames::templateTag))
> 
> #if ENABLE(TEMPLATE_ELEMENT)

done

>> Source/WebCore/inspector/front-end/DOMAgent.js:78
>> +    if (payload.templateContent) {
> 
> No need for {} around one line block.

done

[Rafael Weinstein]

Created attachment 181119 [details]
Patch

[Rafael Weinstein]

Ok, trying Pavel's suggestion.

[Early Warning System Bot]

Comment on attachment 181119 [details]
Patch

Attachment 181119 [details] did not pass qt-ews (qt):
Output: http://queues.webkit.org/results/15625750

[Early Warning System Bot]

Comment on attachment 181119 [details]
Patch

Attachment 181119 [details] did not pass qt-wk2-ews (qt):
Output: http://queues.webkit.org/results/15636645

[Build Bot]

Comment on attachment 181119 [details]
Patch

Attachment 181119 [details] did not pass mac-ews (mac):
Output: http://queues.webkit.org/results/15630745

[Build Bot]

Comment on attachment 181119 [details]
Patch

Attachment 181119 [details] did not pass win-ews (win):
Output: http://queues.webkit.org/results/15628765

[Rafael Weinstein]

Created attachment 181141 [details]
Patch

[Pavel Feldman]

Comment on attachment 181141 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=181141&action=review

> Source/WebCore/dom/Document.cpp:616
> +        m_inertDocument.clear();

This will happen on its own.

> Source/WebCore/dom/Document.cpp:5949
> +Document* Document::inertDocument()

I don't find the new name self-explanatory, I'd rather leave it as is. r- is for this, otherwise lgtm.

[Rafael Weinstein]

Comment on attachment 181141 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=181141&action=review

>> Source/WebCore/dom/Document.cpp:616
>> +        m_inertDocument.clear();
> 
> This will happen on its own.

done

>> Source/WebCore/dom/Document.cpp:5949
>> +Document* Document::inertDocument()
> 
> I don't find the new name self-explanatory, I'd rather leave it as is. r- is for this, otherwise lgtm.

I renamed this one to avoid having to call the back pointer "templateContentsOwnerDocumentOwner" (what is currently "inertDocumentCreator").

I suppose I could go with "templateContentsOwner" and "templateContentsOwnerCreator"? ("Document" is implied in the type).

Thoughts?

[Rafael Weinstein]

Created attachment 181180 [details]
Patch

[Rafael Weinstein]

How ya like me now?

[Rafael Weinstein]

Created attachment 181384 [details]
Patch

[Rafael Weinstein]

New patch resolves merge conflicts.

Pavel: ping?

[Rafael Weinstein]

Created attachment 181776 [details]
Patch for landing

[WebKit Review Bot]

Comment on attachment 181776 [details]
Patch for landing

Clearing flags on attachment: 181776

Committed r139132: <http://trac.webkit.org/changeset/139132>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.