Template element content not inert




5 years ago
a month ago


(Reporter: jonathan, Unassigned)


(Blocks 1 bug)

31 Branch

Firefox Tracking Flags

(Not tracked)



(1 attachment)



5 years ago
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Firefox/33.0
Build ID: 20141027150301

Steps to reproduce:

With html document

<!doctype html>
<meta charset="utf-8">
<template><meta http-equiv="refresh" content="0; url=#require-template"></template>
<noscript><meta http-equiv="refresh" content="0; url=#require-javascript"></noscript>

Actual results:

#require-template appears in address bar

Expected results:

The meta refresh should be inert so not happen.

In an older firefox it didn't refresh (can't remember version.)
Tried today's 31esr, 33, nightly all refresh.
> Tried today's 31esr, 33, nightly all refresh.

I don't see 33 or nightly refreshing on the testcase on Mac.  Don't have ESR31 on hand to test....

Are you seeing this in a clean profile?
Flags: needinfo?(jonathan)

Comment 2

5 years ago
My 31esr test was on freebsd.
Just tried;
33.0.2 new profile linux and win7 both show it.
Tried on localhost server (instead of file) also same.

It is only a single refresh that adds #require-template to address. Pressing reload after causes repeat refreshing.

Adding this to bottom shows the red box.
<style>a#require-template:target~div {width:50px; height:50px; background-color:red;}</style>
<a id="require-template"></a>
Flags: needinfo?(jonathan)
Hmm.  I see this now; I have no idea why I couldn't reproduce this yesterday.

I also see it with all Firefox versions I have on hand, including 22 (the first one that supported <template>), so I expect this never worked.

Should something in nsHtml5TreeBuilder::elementPopped be checking for template before doing the eTreeOpProcessMeta bit?

Or should we just move the <meta> processing out of the parser and into HTMLMetaElement?
Component: General → DOM
Ever confirmed: true
Flags: needinfo?(wchen)
(In reply to Boris Zbarsky [:bz] from comment #3)
> Or should we just move the <meta> processing out of the parser and into
> HTMLMetaElement?

The parser specifies processing certain meta properties during parsing, but we process all properties during the same step. We should probably move the non-parser stuff to HTMLMetaElement (I think this would also fix this template inertness issue for the meta tag).

I've attached a bandaid fix for now.
Flags: needinfo?(wchen)
Do we have a shadow dom tracker this should block?
Flags: needinfo?(wchen)
This bug isn't shadow DOM related, but we can let it block the web components bug.
Flags: needinfo?(wchen)


10 months ago
Priority: -- → P5
Component: DOM → DOM: Core & HTML
Product: Core → Core
You need to log in before you can comment on or make changes to this bug.