Open Bug 801748 Opened 12 years ago Updated 2 years ago

Does not warn/prevent some types of redirects when accessibility.blockautorefresh is true

Categories

(Firefox :: Disability Access, defect)

Product:
Firefox
Component:
Disability Access
Version:
21 Branch
Type:
defect

Tracking

()

People

(Reporter: majuki, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: access, Whiteboard: [bugday-20131016]) 

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20100101 Firefox/15.0.1
Build ID: 20120905151427

Steps to reproduce:

Went to a website


Actual results:

Got redirected without warning


Expected results:

Firefox should have stopped the redirect and sent up a warning message.
This bug was obviously not reported well by me, I was a little frustrated at the time.  There are a couple components to the bug.

1) http://www.cbc.ca/weather/ This page shows an example where FF recognizes that the page is attempting to redirect and prompts with the "Allow" button.  The prompt is then immediately removed and the page redirects before the user clicks anything.  This uses a simple window.location redirect.

2) Cases were FF doesn't recognize that the page is being redirected and doesn't prompt the user at all.  These scripts often use the same technique as http://adblockdetector.com/ code and obscuring the redirect and redirect URL inside an eval() with octal or hexadecimal values.
OS: Windows 7 → All
Hardware: x86_64 → All
Version: 15 Branch → 21 Branch
Updated - any reason this has been untriaged for 8 months?
(In reply to Mark from comment #1)
> 2) Cases were FF doesn't recognize that the page is being redirected and
> doesn't prompt the user at all.  These scripts often use the same technique
> as http://adblockdetector.com/ code and obscuring the redirect and redirect
> URL inside an eval() with octal or hexadecimal values.

If eval() is only an example and this is intended to be this general, maybe it's a duplicate of bug 687300?
Blocks: 687300
Whiteboard: [bugday-20131016]
It could probably be lumped in with 687300 though octal/hex values are not addressed there and need to be as redirects which are currently captured will fail to capture when using said values.
Apologies for my obtuseness, but where does this pref to warn about redirects live? Casual searching on MXR (source code index) finds me an HTTP prompt pref, but it's true by default and I don't see what message we use here - none of the testcases on bug 687300 show anything for me. :-\
Flags: needinfo?(majuki)
Tools->Options->Advanced->General->Accessibility - "Warn me when pages try to redirect or reload the page"
Flags: needinfo?(majuki)
Further example of it failing: slashdot.org - used to be meta http-equiv="refresh" content="1200000" - now uses window.location - both failed to warn the user.

Note this bug should probably also include an enhancement request which does the following:

1) Splits reloading and redirecting as they're separate behaviours 
2) Add whitelist functionality to allow user decisions to be remembered - this would be site wide, first party only.  If added it must be whitelist and not blacklist to prevent redirect loops before they occur.  Probably not necessary to have a whitelist for reloads since they are rare and can be done on a session basis.
3) Flag tabs that have redirect/reload code to allow them to execute properly after a session restoration.  A simple example of why this is desired: webmail tabs or reddit live feeds or the like - these often indicate new messages in the title but will stop executing after a crash unless the tab is revisited.  The user cannot be expected to know this is required.
Status: UNCONFIRMED → NEW
Ever confirmed: true
See Also: → 803590
Summary: Does not warn/prevent redirects → Does not warn/prevent some types of redirects when accessibility.blockautorefresh is true
Simple, more common, example on how to reproduce the "Warn->Redirect before user selection" is to go to mail.google.com when already logged in to gmail.
Marco, can you explain the aims of this setting and how it relates to a11y?
Component: Untriaged → Disability Access
Flags: needinfo?(mzehe)
Keywords: access
I think there are indeed two issues being mixed up here. One is the blocking of redirects, for example in some cases when opening a link from within Gmail. Another, today less common, occurrence, which I think is what the setting was originally about, are pages that automatically refresh themselves, not via JS, but via periodic full page reloads. I haven't seen those in a long time, but those are the ones that make sense regarding the setting. Full page reloads are problematic because they cause the screen reader user to lose context. The page is reloaded, as if someone had clicked a link to another page, and the screen reader starts from the top.

Redirects, as mentioned here also, are different since they just usually mean the original address has become invalid or such, or the URL is a temporary URL that resolves to the final one. That is when I see the prompt "Firefox has blocked you from being redirected to another site".
Those are, however, not really problematic since the temporary URLs are normally not useful for the screen reader user anyway.

So first, it should be determined what is meant here: Redirects, which are not that problematic, or reloads, which are.
Flags: needinfo?(mzehe)
There are several issues Marco did not address:

1) The JS technique used for full page reloads is the same as that used for other redirects (as exampled on slashdot.org) which is possibly why they were linked into one setting in the first place.

2) Temporary links are desirable to prevent for the average user regardless of screen reader issues.  A simple example would be click-fraud sites; A site appears to a search engine to be one thing but as soon as you land on that site it redirects the user to something else (usually drive-by malware, porn, or shopping sites).  In the case of malware I can envision a simple technique using a combination of 2 and 2.1 and only redirecting users who display an exploitable version of FF/plugin/etc while otherwise remaining under the radar.

2.1) Another example related to 2 is adblock detection scripts (and similar) which redirect the user based on detected features creating a hostile environment, not only between sites and users but also between site developers and addon developers.  In the specific case of adblock detection, they actually require you delete the addon not just disable it.

3) Another consideration is users not wanting to be tracked by such redirects and giving the user an opportunity to prevent it. (this is a minor consideration though due to the plethora of other tracking methods that would not be prevented)

4) iframes might be a consideration (not 100% on this, I'd need to investigate further)
(In reply to Marco Zehe (:MarcoZ) from comment #10)

> I think there are indeed two issues being mixed up here. 

> One is the blocking
> of redirects, for example in some cases when opening a link from within
> Gmail. Another, today less common, occurrence, which I think is what the
> setting was originally about, are pages that automatically refresh
> themselves, not via JS, but via periodic full page reloads. I haven't seen
> those in a long time, but those are the ones that make sense regarding the
> setting. Full page reloads are problematic because they cause the screen
> reader user to lose context. The page is reloaded, as if someone had clicked
> a link to another page, and the screen reader starts from the top.

Indeed, this is a problem for the user. On some news sites, the pages auto-reload themselves very frequently (5 min or so). 
You are writing a comment... Boom ! The page reloads itself, you lose your text. 
You are watching a video... Boom ! The page reloads itself, the video is stopped and back at its beginning. 
Not very nice user experiences. 
Let's put the user in control.

> Redirects, as mentioned here also, are different since they just usually
> mean the original address has become invalid or such, or the URL is a
> temporary URL that resolves to the final one. That is when I see the prompt
> "Firefox has blocked you from being redirected to another site".
> Those are, however, not really problematic since the temporary URLs are
> normally not useful for the screen reader user anyway.

In some cases, the origin address is useful. Some origins randomly redirect to some ad page, or to a useless 404 page, or to the home page... In these cases, the user often needs a way to go back at the origin, before the redirect, AND TO STOP THERE.
(In reply to JMJimmy from comment #7)

> 3) Flag tabs that have redirect/reload code to allow them to execute
> properly after a session restoration.  A simple example of why this is
> desired: webmail tabs or reddit live feeds or the like - these often
> indicate new messages in the title but will stop executing after a crash
> unless the tab is revisited.  The user cannot be expected to know this is
> required.

What you want here is not clear to me. At last Firefox now restores pages lazily. Self-reloading pages don't have a privilege which would make them break this.
See Also: → 1064962
(In reply to Nicolas Barbulesco from comment #13)
> (In reply to JMJimmy from comment #7)
> 
> > 3) Flag tabs that have redirect/reload code to allow them to execute
> > properly after a session restoration.  A simple example of why this is
> > desired: webmail tabs or reddit live feeds or the like - these often
> > indicate new messages in the title but will stop executing after a crash
> > unless the tab is revisited.  The user cannot be expected to know this is
> > required.
> 
> What you want here is not clear to me. At last Firefox now restores pages
> lazily. Self-reloading pages don't have a privilege which would make them
> break this.

That would be an enhancement request and I have split it off into bug 1064962.
This option has no effect on http://www.sports.fr/ URL's that autorefresh, such as: http://www.sports.fr/football/directs/ligue-1/lyon-monaco.html (such URL's autorefresh every minute, and the scroll position is lost!)
http://www.bbc.com/news/technology-29241563 - this is the type of thing that can be prevented with this feature working properly.
I ran into a situation where this bug enables bad sites to effectively lock a user onto a page.  Using the "leave page" confirmation prompt they interrupt the tab closing or navigation away from a page, then use location.redirect to re-direct to itself.  Ultimately I had to use Firebug's break on next to escape the loop.
(In reply to JMJimmy from comment #17)
> I ran into a situation where this bug enables bad sites to effectively lock
> a user onto a page.  Using the "leave page" confirmation prompt they
> interrupt the tab closing or navigation away from a page, then use
> location.redirect to re-direct to itself.  Ultimately I had to use Firebug's
> break on next to escape the loop.

That isn't this bug, that's bug 1046022. Should be fixed on Firefox 34 and later. Please file a new bug blocking bug 1046022 if you can still reproduce that issue on 34.
Note also that Firefox's location object doesn't have a "redirect" method, so I'm not sure what exactly you're referring to. In any case, not this bug's problem.
You're correct, though it would have also been prevented by a fix for this feature as well. location.redirect was a brainfart - was thinking about location.reload likely being able to do the same as I was typing... came out as a bastard combination of the two lol  cheers.
See Also: → 1150311
"can you explain the aims of this setting and how it relates to a11y?"

Not Marco, but sometimes Adobe's site strobes because it reloads several times per second. I can't risk going there to check what settings do and don't set it off, but the "warn me" setting doesn't block the reloads.

So there are several things that don't warn the user:

By the way, I don't recommend enabling accessibility.blockautorefresh at the moment since it randomly fails to warn and redirect the user due to a bug (you may see blank pages on some websites): https://bugzilla.mozilla.org/show_bug.cgi?id=1070713

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.