Open
Bug 1090513
Opened 11 years ago
Updated 3 years ago
Template element content not inert
Categories
(Core :: DOM: Core & HTML, defect, P5)
Tracking
()
NEW
People
(Reporter: jonathan, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
|
1.20 KB,
patch
|
Details | Diff | Splinter Review |
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•11 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•10 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•10 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)
|
||
Comment 4•10 years ago
|
||
(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 6•10 years ago
|
||
This bug isn't shadow DOM related, but we can let it block the web components bug.
Blocks: webcomponents
Flags: needinfo?(wchen)
|
|
||
Updated•7 years ago
|
Priority: -- → P5
|
Assignee | |
Updated•6 years ago
|
Component: DOM → DOM: Core & HTML
|
||
Updated•3 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•