Note: There are a few cases of duplicates in user autocompletion which are being worked on.

Template element content not inert

NEW
Unassigned

Status

()

Core
DOM
3 years ago
4 months ago

People

(Reporter: Jonathan Howard, Unassigned)

Tracking

(Blocks: 1 bug)

31 Branch
x86_64
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

3 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>
<title>Test</title>


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.

Comment 1

3 years ago
> 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)
(Reporter)

Comment 2

3 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>
<div></div>
Flags: needinfo?(jonathan)

Comment 3

3 years ago
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?
Status: UNCONFIRMED → NEW
Component: General → DOM
Ever confirmed: true
Flags: needinfo?(wchen)
Created attachment 8516088 [details] [diff] [review]
Bug 1090513 - Make <meta> inert in template contents.

(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)

Comment 5

3 years ago
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.
Blocks: 811542
Flags: needinfo?(wchen)
You need to log in before you can comment on or make changes to this bug.