Open
Bug 1090513
Opened 10 years ago
Updated 2 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•10 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•6 years ago
|
Priority: -- → P5
|
Assignee | |
Updated•5 years ago
|
Component: DOM → DOM: Core & HTML
|
||
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•