User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:188.8.131.52) Gecko/20090730 Iceweasel/3.5.1 (Debian-3.5.1-1) Build Identifier: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:184.108.40.206) Gecko/20090730 Iceweasel/3.5.1 (Debian-3.5.1-1) The label for the checkbox to control accessibility.blockautorefresh in Preferences -> Advanced -> General, Accessibility is "Warn me when web sites try to redirect or reload the page": #: blockAutoRefresh.label #: blockAutoRefresh.accesskey msgid "Warn me when we&b sites try to redirect or reload the page" This is not exactly what this preference does. The preference seems properly documented on http://kb.mozillazine.org/Accessibility.blockautorefresh This preference only warns when a page redirects to another one via an HTML META element. It takes no effect when being redirected by an actual HTTP header such as 301 and 302. So the bug seems to be in the wording of the label. The behavior seems correct, although the documentation page does discuss HTTP Refresh header. Reproducible: Always Steps to Reproduce: No real step, but you can verify that accessibility.blockautorefresh does not block HTTP 301 by activating the option and going to http://ww.google.ca Actual Results: Quiet redirection to http://www.google.ca Expected Results: Prompt for confirmation before redirecting
So, as the bug summary and Expected Results want this pref to apply to HTTP 301 and 302, when it was never meant for that, this bug should be resolved WONTFIX, given the HTTP specification does not allow for user interaction of these headers and how badly such behaviour would completely break normal functioning for things like switching from http to https to ensure secure logins. Yet, this line "So the bug seems to be in the wording of the label." hints that you just want the wording to clarify that it doesn't apply to 301 and 302 redirects (note these are not the HTTP Refresh header mentioned in the documentation). If my second paragraph is accurate then change the summary to: "Warn me when web sites try to redirect or reload the page" wording could be mistaken to apply to HTTP Location header (301, 302) with a revised "Expected Results" to "A non-confused user that realises this is not the function of that pref"
Mardeg, the Steps to Reproduce section indicates that there is no real need to reproduce. These are steps to "verify that accessibility.blockautorefresh does not block HTTP 301". As the for the summary, the current one may be misleading, but "could be mistaken" is too weak - the label can't be red differently.
I'm setting Importance back to Normal. This is a bug report, not a request for enhancement.
Severity: enhancement → normal
Changing summary in line with comments.
Summary: "Warn me when web sites try to redirect or reload the page" for accessibility.blockautorefresh does not apply to HTTP Location header (301, 302) → Change "Warn me when web sites try to redirect or reload the page" checkbox label for accessibility.blockautorefresh to non-misleading text: it does not apply to HTTP Location header (301, 302)
Could you suggest a better wording for the option? I think it may be hard, the Refresh meta tag is often used for refreshing the current page but also for redirecting to completely different URL.
I agree. I think the current description tried to be user-friendly and to reflect that rather than to allude to its technical meaning. Unfortunately that made it inexact. The current label is: Warn me when web sites try to redirect or reload the page The description on mozillazine is: Web pages (and web servers) can ask a browser to automatically refresh a page after a given timeout by including the HTML element <meta http-equiv="refresh"> or by sending a Refresh: HTTP header. This can be helpful (as in the case of a webpage whose content is updated constantly) but it also can be irritating. I guess a good label should be both user-friendly and correct. I would suggest this synthesis: Request confirmation when web sites try to redirect or reload the page via a Refresh HTTP header. This could possibly be clarified / made more exact by talking about the HTML meta element (http-equiv), if someone has a good wording to suggest.
That is quite a long title :) However, there is a Help button in the Preferences dialog, that points to http://support.mozilla.com/en-US/kb/Options%20window%20-%20Advanced%20panel?as=u . The only description of this option is this: "Warn me when websites try to redirect or reload the page: When this option is enabled, Firefox will prevent websites from redirecting you to another page, or automatically reloading." Maybe it could be described more precisely here. This text currently doesn't add any information above the wording in the prefs dialog.
Assignee: nobody → zfang
Please change the text to: "Warn me when a web page tries to reload or replace itself."
(In reply to Rahul from comment #8) > Please change the text to: > > "Warn me when a web page tries to reload or replace itself." This is not what the pref is supposed to do - the pref does not do its job in all cases, but this is another story. To be more exact, let's rather say : "Ask me before a Web page reloads or replaces itself." Nicolas
(In reply to Nicolas Barbulesco from comment #9) > "Ask me before a Web page reloads or replaces itself." This is a perfectly valid proposal. We should also note: Looking at the history of this problem report, I see that the point behind the original report was not the distinction between "warn" and an "ask", but rather, the distinction between HTML-caused reloading and Location-header-caused reloading. Between 2009 and now (2012) nobody has objected to saying "warn" instead of "ask", so I think we can safely assume that most people don't much care about the warn/ask distinction.
(In reply to Rahul from comment #10) > Between 2009 and now (2012) nobody has > objected to saying "warn" instead of "ask", so I think we can safely assume > that most people don't much care about the warn/ask distinction. That's forgetting bug 510186 comment 0, bug 510186 comment 6, bug 510186 comment 9, bug 443254 comment 0, bug 443254 comment 4, bug 443254 comment 8, bug 443254 comment 9, bug 443254 comment 10, bug 443254 comment 15.
This is still confusing in Firefox 42.0 (current). My interpretation of the discussion so far is that the preference: 1. Does affect Refresh via HTML META tag 2. Does affect Refresh via HTTP header 3. Does NOT affect redirect due to HTTP "Moved" response 301 or 302 Assuming the above is both true and intended, then the label could simply be changed to say "reload" only and not "redirect". The subtlety is that Refresh can in fact be used to redirect. The word "refresh" could be used instead of "reload" to be technically correct. But "redirect" should not be used unqualified, because of 3. My understanding is that 3 is deliberate because this is an accessibility, not a security, feature: it is not necessary to catch a "bare" redirect, which has no associated rendering, and 3 is always such. The fact that Refresh, which is not always such, MAY also be used for this purpose is unfortunate. An alternative approach would be to widen the scope beyond accessibility, i.e. to enable blocking of all redirects, by having a new preference controlling 3. The UI could then stay the same and turn on or off both preferences together. For what it's worth, I've had this preference turned on for a while, and almost all catches are bare redirects, so it seems that (at least for my usage profile) most Refresh's in fact mirror 3 rather than being traditional reloads to update page content (which may be done in other ways these days). So the logic behind the original design itemised above may have been correct then but now out of date.
Just for reference, it seems that network.http.redirection-limit=0 would accomplish blocking "Moved"-type redirects (number 3 above). However, I suppose it wouldn't currently offer the same option to bypass the block, so that there would still be work to do to integrate this seamlessly with accessibility.blockautorefresh (the "alternative approach" described above).
You need to log in before you can comment on or make changes to this bug.