Note: There are a few cases of duplicates in user autocompletion which are being worked on.

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

NEW
Unassigned

Status

()

Firefox
Disability Access
5 years ago
6 months ago

People

(Reporter: JDev, Unassigned)

Tracking

(Blocks: 1 bug, {access})

21 Branch
access
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [bugday-20131016])

(Reporter)

Description

5 years ago
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.
(Reporter)

Comment 1

5 years ago
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.
(Reporter)

Updated

4 years ago
OS: Windows 7 → All
Hardware: x86_64 → All
Version: 15 Branch → 21 Branch
(Reporter)

Comment 2

4 years ago
Updated - any reason this has been untriaged for 8 months?

Comment 3

4 years ago
(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]
(Reporter)

Comment 4

4 years ago
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.

Comment 5

3 years ago
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)
(Reporter)

Comment 6

3 years ago
Tools->Options->Advanced->General->Accessibility - "Warn me when pages try to redirect or reload the page"
Flags: needinfo?(majuki)
(Reporter)

Comment 7

3 years ago
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.

Updated

3 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
See Also: → bug 803590
Summary: Does not warn/prevent redirects → Does not warn/prevent some types of redirects when accessibility.blockautorefresh is true
(Reporter)

Comment 8

3 years ago
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.

Comment 9

3 years ago
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)
(Reporter)

Comment 11

3 years ago
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)

Comment 12

3 years ago
(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.

Comment 13

3 years ago
(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.
(Reporter)

Updated

3 years ago
See Also: → bug 1064962
(Reporter)

Comment 14

3 years ago
(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.

Comment 15

3 years ago
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!)
(Reporter)

Comment 16

3 years ago
http://www.bbc.com/news/technology-29241563 - this is the type of thing that can be prevented with this feature working properly.
(Reporter)

Comment 17

3 years ago
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.

Comment 18

3 years ago
(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.

Comment 19

3 years ago
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.
(Reporter)

Comment 20

3 years ago
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.

Updated

2 years ago
See Also: → bug 1150311

Comment 21

6 months ago
"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.
You need to log in before you can comment on or make changes to this bug.