meta refresh outside of <noscipt> is blocked

al_9x · Post by **al_9x** » Mon May 31, 2010 5:49 pm

if <noscript> is exists somewhere in the page

<html>
<head>
<meta http-equiv="refresh" content="0;url=http://www.google.com/">
</head>
<body>
<noscript></noscript>
</body>
</html>

processMetaRefresh doesn't check if <meta> is inside <noscript>

fx 3.6.3, ns 1.9.9.84

Post by **Giorgio Maone** » Mon May 31, 2010 9:07 pm

Unfortunately that's the only valid heuristic to implement this feature, because Gecko's HTML parser has the bad habit of moving to head META elements found in the body, leaving the surrounding <NOSCRIPT> elements in their original places.

For instance,

Code: Select all

<html>
<head>
</head>
<body>
<noscript><meta http-equiv="refresh" content="0;url=http://www.google.com/"></noscript>
</body>
</html>

internally becomes exactly identical to your sample, i.e.

Code: Select all

<html>
<head>
<meta http-equiv="refresh" content="0;url=http://www.google.com/">
</head>
<body>
<noscript></noscript>
</body>
</html>

The new HTML 5 parser in Firefox 4 doesn't perform this kind of unexpected transformations, therefore I'll be able to be more precise. Will drop a conditional path for pref("html5.enabled") == true in next build.

dhouwn · Post by **dhouwn** » Tue Jun 01, 2010 1:28 am

Is the new parser always used when the pref is set? What about quirks mode, XHTML and other edge cases?

Post by **Giorgio Maone** » Tue Jun 01, 2010 5:49 am

dhouwn wrote:Is the new parser always used when the pref is set?

Yes it is.

dhouwn wrote:What about quirks mode, XHTML and other edge cases?

HTML 5, differently from HTML 4 and XHTML, aside conformance rules specifies also rules for parsing (something sorely missing from previous specification, and one of the causes of the browser compatibility hell).
These rules have been agreed upon by browser vendors, picking the most common/reasonable behavior among existing browsers.
Therefore in most cases (like this), unreasonable and/or niche quirks just go away also for legacy HTML 4/XHTML documents, which are parsed by the new parser.

Anyway, latest development build implements the aforementioned behavior.

dhouwn · Post by **dhouwn** » Wed Jun 02, 2010 6:15 pm

Did a little test in Firefox trunk with the HTML5 parser activated and meta-refresh redirections inside noscript-tags are not blocked for XHTML:

Code: Select all

<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head></head>
<body>
<noscript><meta http-equiv="refresh" content="0;url=http://www.example.org/" /></noscript>
</body>
</html>

(Save as .xhtml)

Post by **Giorgio Maone** » Wed Jun 02, 2010 6:37 pm

dhouwn wrote:Did a little test in Firefox trunk with the HTML5 parser activated and meta-refresh redirections inside noscript-tags are not blocked for XHTML:
Code: Select all
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head></head>
<body>
<noscript><meta http-equiv="refresh" content="0;url=http://www.example.org/" /></noscript>
</body>
</html>
(Save as .xhtml)

They are blocked for me, using your source both from a local .xhtml file and from http://evil.hackademix.net/test/meta/xhtml.xhtml
Is the relevant NoScript|Untrusted option checked?

al_9x · Post by **al_9x** » Wed Jun 02, 2010 6:50 pm

blocked for me as well with:

Code: Select all

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a5pre) Gecko/20100531 Minefield/3.7a5pre

One thing I noticed, no blocked alert bar on back or forward (fx 3.6.3 & minefield)

Post by **Giorgio Maone** » Thu Jun 03, 2010 12:30 am

al_9x wrote:One thing I noticed, no blocked alert bar on back or forward (fx 3.6.3 & minefield)

The bar happens on DOMContentLoaded, which doesn't fire if a page is in the BFCache.

al_9x · Post by **al_9x** » Thu Jun 03, 2010 1:41 am

Giorgio Maone wrote:
al_9x wrote:One thing I noticed, no blocked alert bar on back or forward (fx 3.6.3 & minefield)
The bar happens on DOMContentLoaded, which doesn't fire if a page is in the BFCache.

Are there perhaps other events, this thread seems to suggest that OnStateChange should fire?

dhouwn · Post by **dhouwn** » Thu Jun 03, 2010 1:49 am

Strange, I tested it with a normal HTML file and one without a DOCTYPE (quirks mode) and it blocked the redirect, but not for the XHTML file.
I can't reproduce this anymore, so I guess I just accidentally allowed the redirect once. Otherwise I would have suspected an extension.

/edit: It remembers the permission for redirection for all local XHTML files once I allowed it for a local file of this type?!
/edit: Yepp, seems so. Save my test file as a .xhtml, open it, allow the redirection, rename it (but leave file extension), open it, and you are instantly redirected, edit file extension to .html and no redirection.

Post by **Giorgio Maone** » Thu Jun 03, 2010 7:35 am

dhouwn wrote:/edit: It remembers the permission for redirection for all local XHTML files once I allowed it for a local file of this type?!

Yes, it remembers by domain (file:/// is treated as a domain).

InformAction Forums

meta refresh outside of <noscipt> is blocked

meta refresh outside of <noscipt> is blocked

Re: meta refresh outside of <noscipt> is blocked

Re: meta refresh outside of <noscipt> is blocked

Re: meta refresh outside of <noscipt> is blocked

Re: meta refresh outside of <noscipt> is blocked

Re: meta refresh outside of <noscipt> is blocked

Re: meta refresh outside of <noscipt> is blocked

Re: meta refresh outside of <noscipt> is blocked

Re: meta refresh outside of <noscipt> is blocked

Re: meta refresh outside of <noscipt> is blocked

Re: meta refresh outside of <noscipt> is blocked