Closed Bug 333231 Opened 18 years ago Closed 17 years ago

NOSCRIPT element is allowed in HEAD, allowing META refresh.

Categories

(Core :: DOM: HTML Parser, defect)

Product:
Core
Component:
DOM: HTML Parser
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: brian.ewins, Assigned: mrbkap)

References

(
URL
)

Details

Attachments

(2 files)

testcase
483 bytes, text/html
Details
proposed patch
1.44 KB, patch
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1

Firefox processes this html:
<HTML><HEAD>
<NOSCRIPT><META http-equiv="refresh" content="0;URL=/include/no-js.html"></NOSCRIPT>
</HEAD>...</HTML>

when javascript is off, respecting the meta tag and redirecting the browser. It shouldn't - noscript is illegal in HEAD and its contents should be ignored.

Reproducible: Always

Steps to Reproduce:
1. Disable javascript
2. visit http://www.archivesat.com
3. observe that you are redirected to http://www.archivesat.com/include/no-js.html

Actual Results:  
Browser is redirected to http://www.archivesat.com/include/no-js.html


Expected Results:  
Browser should have stayed at http://www.archivesat.com

Obviously this trick is taking advantage of quirks-mode behaviour since the markup isn't valid. However, even allowing this behaviour in quirks mode is pretty nasty, it lets sites universally block access to scriptless browsers.
Related to Core bug 21008 comment 3?
(In reply to comment #1)
> Related to Core bug 21008 comment 3?
> 

you're quite right, I'd missed pre-firefox noscript bugs in my search.

I'd like to think stop-evil-behaviour trumps backwards-compatibility but if the old decision stands I won't shout if this gets marked WONTFIX.
just reread bug 21008, realised its not fixed, or is a regression. The original bug report said: 
"The parser needs to deal with <noscript> in head better than it does (even
though it's illegal). The real fix is to open <noscripts> in the head, but
ignore meta, link, etc. over in the content sink."

which this bug dupes, but the test case attached to 21008 doesn't include any meta/link/etc tags (neither did the bugs that blocked it; all of the test cases I can see generated content). So its unclear if the original bug was fixed.
Assignee: nobody → mrbkap
Component: General → HTML: Parser
OS: MacOS X → All
Product: Firefox → Core
QA Contact: general → parser
Hardware: Macintosh → All
Version: unspecified → Trunk
Attached file testcase — 
corrected testcase, adapted from the one on bug 21008. The desired behaviour is that in noscript-in-head, head- and body- related content are treated differently; the test shows that they are not. Patch to follow.
Attached patch proposed patch — — Splinter Review 
this patch makes the change describe in bug 21008. It has the side effect of treating 'link' the same as 'meta' in noembed-in-head and noframes-in-head.
I'm not sure that I agree with the premise of this bug: that meta refreshes shouldn't be allowed if scripts are disabled (is that the premise?). The comments in bug 21008 all relate to the opposite case that this bug is addressing: namely, when scripts are enabled. We used to have bugs where we would respect <link> and <meta> tags that were children of <noscript> tags, even with scripts *enabled*.

In fact, I'm wondering if that if statement in AddHeadContent shouldn't be removed altogether. It seems arbitrary to not allow scripts inside of <noframe>s...
(In reply to comment #6)
> I'm not sure that I agree with the premise of this bug: that meta refreshes
> shouldn't be allowed if scripts are disabled (is that the premise?). 

Not quite. The bug is that meta refreshes and links triggered by *disabling* scripts aren't allowed by the html standards. I'm perfectly ok with meta refreshes being allowed unconditionally, since thats what the standards dictate. The patch I put in here doesn't stop metas when scripts are disabled, only metas inside noscript tags inside head tags.

> The comments in bug 21008 all relate to the opposite case that this bug is
> addressing: namely, when scripts are enabled. We used to have bugs where we
> would respect <link> and <meta> tags that were children of <noscript> tags,
> even with scripts *enabled*.

I see what you mean. So this doesn't dupe 21008, but is instead a new argument that this stuff should never have worked? 

> In fact, I'm wondering if that if statement in AddHeadContent shouldn't be
> removed altogether. It seems arbitrary to not allow scripts inside of
> <noframe>s...

I'm not sure I agree. Remember that this code applies to noframes, noscript, or noembed *inside* head, all of which are illegal constructs normally. Quirks mode is only tolerating these at all to support sites that used these before (pre-y2k). Given the test cases for 21008 and related bugs, what was being supported then was misplaced body content in a head no* element. 

With illegal, quirks-mode markup it's up to the ffox devs what arbitrary behaviour they want to condone. All I'm saying is, leaving a way to block all clients with javascript off is behaviour you *dont* want to condone, and isn't something that is supported by any html spec. 
I don't agree with this bug.

The XHTML standard should be changed to allow NOSCRIPT in HEAD.  Web developers need the flexibility to say what tags (i.e., META, STYLE, etc.) in the header should be used if Javascript isn't enabled.  This is one of those rare areas where I say "eff the standard!".

"Fixing" this "bug" would undoubtedly break a lot of sites.  By the way, NOSCRIPT in HEAD is respected by both Opera and IE6.  Please don't make Firefox/Gecko an exception.
(In reply to comment #8)
> The XHTML standard should be changed to allow NOSCRIPT in HEAD.  Web developers
> need the flexibility to say what tags (i.e., META, STYLE, etc.) in the header
> should be used if Javascript isn't enabled.  This is one of those rare areas
> where I say "eff the standard!".

You still have that flexibility. However, instead of saying what should happen when JS is disabled, you get full flexibility to manipulate the DOM, redirect the browser, etc, when JS is *on* - exactly as in standards mode. The only thing this bugfix prevents is putting a one-liner on your pages to block scriptless browsing, while being indexed by google (see below).

You can still block scriptless browsing by generating the site dynamically, GWT-style. However, this drops you off the search engines.

> "Fixing" this "bug" would undoubtedly break a lot of sites. 
Very, very few sites use this as far as I can tell (I browse with the NoScript extension on and have only seen 2; http://code.google.com/webstats doesnt mention anything relevant), - but the content-generating NOSCRIPTs covered by bug 21008, which appeared on many sites in the distant past, still work with this fix.

> By the way,
> NOSCRIPT in HEAD is respected by both Opera and IE6.  Please don't make
> Firefox/Gecko an exception.

The my-browser-does-X argument could be used to support the inclusion of all IE bugs in Firefox :) However, since we're citing other browsers - Safari *doesnt* respect NOSCRIPT-in-head (presumably the other WebKit based browsers are the same). More importantly, NOSCRIPT-in-head isn't respected by the google spider, so this is being used as a way of presenting different content to users from what Google sees. 

Marking this WONTFIX. Since I raised it, I've still only seen two other sites that use the trick (archivesat stopped doing it but here's a new example - http://www.avantibikes.com/news/news.aspx ), but also a few things have changed:

- Safari now allows it.

- WHATWG has allowed it in Web Applications 1.0, v 21 April 2007 - noscript has a transparent content model and is legal in 'head', hence it can contain meta tags. So this may end up as legal html 5. Given that its even more unlikely firefox would want to change. Also, standardisation will hopefully get the feature supported in the google spider, which would drop sites using it off the index (evil grin).

- there is now a workaround - the NoScript extension, Version 1.1.4.8, contains an option to block head/noscript/meta.
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: