If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Extended template element has no content property

RESOLVED INVALID

Status

()

Core
DOM
RESOLVED INVALID
2 years ago
2 years ago

People

(Reporter: Luis Garcia, Unassigned)

Tracking

37 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

2 years ago
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)})
  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?
Flags: needinfo?(lohentertainment)
(Reporter)

Comment 2

2 years ago
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?
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.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 2 years ago
Flags: needinfo?(lohentertainment)
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.