After 10 months, 17 rounds of patch and review, and two last-minute corrections, bug 83265 has landed. Firefox 3 will include an option to block timed redirects (a.k.a. META refresh tags). By default, Firefox 3 will act like Firefox 2, i.e. it will respect META refresh tags as it always has. But now the end user will have the option to block them:
I can not stress enough that this checkbox is off by default. Users who install or upgrade to Firefox 3 will not see any difference unless they intentionally select this checkbox to turn the warnings on.
This is primarily an accessibility feature. Browsers are supposed to allow users to control all timeouts, but Firefox has never provided a way to control timed redirects. This is not a theoretical problem. Millions of web pages use timed redirects, and blind users who use text-to-speech software get confused when the page changes before the software has a chance to read the explanation of what’s about to happen.
If you turn this option on and go to a page that uses a timed redirect, you will see a notification bar at the top of your browser window:
As the notification bar says, the browser has completely blocked the timed redirect. The page will not redirect automatically, no matter how long you wait. You must press the “Allow” button, at which point it will immediately redirect to the target page without any further delay.
Geeky technical footnotes:
- The notification bar is exposed to assistive technologies as an ALERT, so it will be read immediately by compatible text-to-speech software.
- If it looks familiar, that’s because it’s the same sort of notification bar you get when Firefox blocks a popup window.
- If you have multiple types of notifications (like a page that tries to open a popup window and redirect you), they will stack visually and queue aurally.
- The “Allow” button is in the tab order and can be accessed by AccessKey + A.
- The option is global; it affects all sites. If you want site-specific control, download an extension like RefreshBlocker.
Great news to many, I guess. An improvement for someone else is an improvement for me.
Comment by David Naylor — Thursday, February 8, 2007 @ 7:17 pm
I’m gonna like this. Thanks for pointing it out.
Comment by Devon Young — Thursday, February 8, 2007 @ 7:24 pm
What about location.reload() from JS? (Yeah, I should have probably read the bug… ;)
Comment by marcoos — Thursday, February 8, 2007 @ 7:39 pm
No, blocking JavaScript-based redirects was out of scope for this bug. Use an extension like NoScript.
Comment by Mark — Thursday, February 8, 2007 @ 8:07 pm
How long have you been hacking on Firefox Mark?
Comment by Noah Slater — Thursday, February 8, 2007 @ 8:14 pm
Will this cover the (admittedly rare) case where the Refresh: header is sent as an HTTP header and not <meta http-equiv…>?
Comment by epc — Thursday, February 8, 2007 @ 8:25 pm
Answering my own question, it looks like the code should cover the case of Refresh: being sent in an HTTP header.
Comment by epc — Thursday, February 8, 2007 @ 8:29 pm
Hurrah! Well done, Mark, and thanks for your patient and persistent efforts.
Comment by Mike Beltzner — Thursday, February 8, 2007 @ 10:15 pm
That is way cool! I’m glad for that news. When is 3.0 going into general release? I have one site that I have to use Dillo to visit, because if I use NoScript to block all their pop-up ads, then the redirect takes me away from the content to a “your browser is not letting you sign in…” page. Fortunately, Dillo does not have JS and it doesn’t automatically redirect either.
Comment by W^L+ — Thursday, February 8, 2007 @ 11:34 pm
1. Why isn’t the option in about:config? (it reminds me of Moz Suite UI clutter)
2. Why doesn’t the altert bar say to WHICH URL the redirect goes?
(sorry, if this is explained in the bug)
Comment by Peter Lairo — Friday, February 9, 2007 @ 2:08 am
I noticed that about half of the comments associated with your patch revolved around the formatting of the source code - have these people never heard of code beautification tools? There are tons of them, and they can eliminate most of these discussions by automating away the committers’
neurosespreferences and fixing whitespace discrepancies.If I were you, I would have told “BZ” to “FOAD” somewhere around comment #58:
BZ: “no, really, why not combine these onto one line?”
DJ: “holy christ wearing flip flops, dude - combine the two lines if that’s what you want. just apply my patch and let’s end the presidential debate.”
Comment by DJ — Friday, February 9, 2007 @ 3:48 am
[10] Read this: http://kb.mozillazine.org/Accessibility.blockautorefresh
Comment by JasnaPaka — Friday, February 9, 2007 @ 6:17 am
Thanks, Mark!
I certainly will use this feature. I always find it annoying when websites are suddenly refreshing while I’m reading some text.
Comment by Martijn — Friday, February 9, 2007 @ 8:16 am
Looks great.
One suggestion for a future version: show at least part of the [sanitized] URL to the user, a la:
Firefox prevented this page from redirecting to: “http://ugly.example.com/blah29320…”
That would make it much easier to decide whether to click ‘Allow’.
(Sorry, I haven’t set up a Bugzilla account yet to submit the suggestion there…)
Comment by Steve B. — Friday, February 9, 2007 @ 3:35 pm
For what little it may be worth, the refreshblocker addon does not block Refresh: when sent as an HTTP header, only <meta refresh>
Comment by epc — Friday, February 9, 2007 @ 8:22 pm
I agree with Steve B, that would be really useful…
Comment by optimointi — Monday, February 12, 2007 @ 8:23 am