1167966 - Extended template element has no content property

Status: RESOLVED INVALID

(Core :: DOM: Core & HTML, defect)

Description

[Luis Garcia]

Such: <template is="e-e">
el.content is undefined

Works in Chrome. Even we do not create template's prototype, like this:
document.registerElement('e-e', {extends: 'template', prototype: Object.create(HTMLTemplateElement.prototype)})

Comment 1

[Boris Zbarsky [:bzbarsky]]

  data:text/html,<template is="e-e"></template><script>alert(document.querySelector("template").content)</script>

works fine for me in both Firefox 37 and current tip.  So does:

  data:text/html,<script>document.registerElement('e-e', {extends: 'template', prototype: Object.create(HTMLTemplateElement.prototype)})</script><template is="e-e"></template><script>alert(document.querySelector("template").content)</script>

on trunk, where registerElement is supported.

Can you please attach whatever testcase this bug report is about?

Comment 2

[Luis Garcia]

Yeah, it is works for me too. It seems, it's does't works if we register element with true template's prototype.
This one doesn't works in Firefox, but works in Chrome:
document.registerElement('e-e', {extends: 'template'});
document.createElement('template', 'e-e').content;

This is Chrome bug or Firefox bug?

Comment 3

[Boris Zbarsky [:bzbarsky]]

Thanks for the clearer explanation.

Looking at the spec at http://w3c.github.io/webcomponents/spec/custom/#dfn-document-registerElement you're passing an ElementRegistrationOptions with a null prototype and "extends" set to "template".

Per step 1 of the spec, PROTOTYPE is set to Object.create(HTMLElement.prototype).

Per step 3 we run http://w3c.github.io/webcomponents/spec/custom/#dfn-element-registration-algorithm with that PROTOTYPE and NAME set to "template".  That drops us in http://w3c.github.io/webcomponents/spec/custom/#dfn-definition-construction-algorithm which ends up creating a DEFINITION with local name set to "template" and custom element prototype set to that PROTOTYPE value.

Next we do the createElement, which creates the element with the prototype stored in the relevant DEFINITION as determined by the second argument.

So the resulting object does not have HTMLTemplateElement.prototype on its prototype chain.  Since the "content" property lives on HTMLTemplateElement.prototype, per spec, the Firefox behavior here is correct.

In Chrome, the prototype chain is also correct.  And in a Chrome dev build, the .content is undefined, for the same reason as in Firefox.

In a release build of Chrome, the property is present because of a known Chrome bug (fixed in their dev builds), where they put some DOM properties directly on the object instead of on the relevant prototype.

In any case, what you should be doing is passing in a prototype to your element registration that has HTMLTemplateElement.prototype on its proto chain, if you want the HTMLTemplateElement bits available on your object.