417770 - META REFRESH redirect warning appears immediately instead of when timer fires

Status: NEW

(Core :: DOM: Navigation, defect)

Description

[David Pfender]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3) Gecko/2008020514 Firefox/3.0b3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3) Gecko/2008020514 Firefox/3.0b3

A page with something like this:
<META HTTP-EQUIV="REFRESH" CONTENT="2700;url=https://admin.xxx.com/page.php">
causes a warning message about being redirected immediately, not when the timer interval has been reached.  The choice is Allow, which causes immediate redirect to the specified url, or [X] to close the warning. If [X] is used, does the timer still run?  Or has it been blocked entirely.  Some websites use this timer feature for security to redirect the user to a warning page that their session will expire if they do not respond to a prompt.

Reproducible: Always

Steps to Reproduce:
1.See details above.
2.
3.
Actual Results:  
if [X] is used, the page can be used normally.  It is not clear if the timer has been disabled.

Expected Results:  
The prompt to Allow the redirection should not appear until the timer interval has been reached.

This does not stop the use of the browser, but nobody in their right mind would put up with this nonsense when it occurs on every page for a website while running with https active.

Comment 1

[Jesse Ruderman]

This only happens if you have checked "Warn me when sites try to redirect or reload the page" in Tools > Options > Advanced > General, right?

Comment 2

[David Pfender]

You are correct.  The message only appears if the warning is checked.  I 
removed the check and now there is no message.  I still believe that the 
message should only appear at the end of the timeout interval so that the 
warning is still useful for all other situations.

Comment 3

[Jesse Ruderman]

What do you guys think?

Comment 4

[TommyWillB]

As I commented in bug 424167, I agree this is a problem and causes the exact user/usability confusion it was intended to eliminate.

My credit union has 600 second meta refresh that's used to timeout the session:
<meta HTTP-EQUIV="Refresh" CONTENT="600; URL=/hb/Timeout.asp">

So, if I login with redirect warning on, I immediately see the redirect
warning. If I do the logical thing and click "Allow", I'm timed-out
immediately.

David Pfender suggests that this warning wait until the timeout, but I also see no problem being asked to "Allow" immediately so long as the timeout is still honored... i.e. keep counting the 600
seconds.

Comment 5

[Jesse Ruderman]

Would it make sense to simply relabel the button from "Allow" to "Go now"?

Comment 6

[TommyWillB]

It would be more "accurate" but not functionally any better.

Comment 7

[Matthew Middleton (:zzxc)]

The current behavior is confusing to users, as they are getting a redirect warning long before a redirect would actually happen.  Delaying the warning until the interval expires seems like the most logical thing to do here, although it might make sense to display it immediately for very short intervals.

Short intervals are often used on advertisements or download pages, where the user is likely to use the "Allow" button as soon as it becomes available.  In these cases, adding a delay might worsen the user experience.

Comment 8

[Per Ångström]

I have disabled META-REFRESH to stop sites from refreshing pages while I'm reading them. That works fairly well, although I'm irritated about the warning bar taking up valuable screen space (and I'm too lazy to close it).

However, Ubuntu Launchpad uses META-REFRESH after the user has uploaded bug information, to periodically check whether the data has been processed on the server side. In Firefox, with the redirection warning enabled the warning prompt appears instantly, so the periodic-check facility is effectively disabled, forcing the user to manually reload the page every now and then.

I would vote for not showing the prompt until the refresh interval fires.

Comment 9

[:aceman]

Attachment: testcase

This is still a problem in Firefox 6. The information bar should only appear when the timeout expires. This would also lower the number of times people even see it, as they may already leave the page before expiration (like the banking site).

Comment 10

[O. Atsushi (Torisugari)]

Attachment: Patch v1

Move RefreshAttempted() from nsIRefreshURI::RefreshURI() to ForceRefreshURIFromTimer(). And s/ForceRefreshURIFromTimer/RefreshURIFromTimer/, since it will no longer *force* to refresh URI.

Comment 11

[O. Atsushi (Torisugari)]

Attachment: Patch v1.1

Fix comments about aTimer were dropped.

Comment 12

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 639006 [details] [diff] [review]
Patch v1.1

This needs tests.

Comment 13

[O. Atsushi (Torisugari)]

Attachment: Test v1 (mochitest-chrome)

I agree this bug needs a testcase, but I'm not too sure exactly what to be tested.

Comment 14

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 639006 [details] [diff] [review]
Patch v1.1


>+    if (!(sameURI && (LOAD_REFRESH == mLoadType)) &&
>+        !RefreshAttempted(this, aURI, aDelay, sameURI)) {
>+        return NS_OK;
>+    }
Oh, wait, we can't change this behavior.
It should be the implementation of  onRefreshAttempted which should perhaps
not handle nested refreshes.

Comment 15

[O. Atsushi (Torisugari)]

(In reply to Olli Pettay [:smaug] from comment #14)
> Comment on attachment 639006 [details] [diff] [review]
> Patch v1.1
> 
> 
> >+    if (!(sameURI && (LOAD_REFRESH == mLoadType)) &&
> >+        !RefreshAttempted(this, aURI, aDelay, sameURI)) {
> >+        return NS_OK;
> >+    }
> Oh, wait, we can't change this behavior.
> It should be the implementation of  onRefreshAttempted which should perhaps
> not handle nested refreshes.

I'm afraid the UI side is not able to detect it is the *first* refresh or not, is it?

Comment 16

[Olli Pettay [:smaug][[e-mail]]]

Well, then we need some new API.
The problem is that there can be other onRefreshAttempted implementations than just the one
for the UI.

Comment 17

[O. Atsushi (Torisugari)]

> The problem is that there can be other onRefreshAttempted implementations
> than just the one
> for the UI.

You are right, though I doubt nested listeners are assumed when the interface was designed. If there are 2 or more onRefresAttempted implementation (e.g. from addon etc.), the browser's behaviour would be just chaotic regardless of the patch.

> Well, then we need some new API.

Hmm...mmm! I don't like to add another arg to this listener for the time being, because I'd rather like to rename the listener to catch JS redirections, e.g. s/onRefreshAttempted/onContentRedirectionAttempted/ or something (bug 687300).

Comment 18

[Olli Pettay [:smaug][[e-mail]]]

Well, docshell could expose what kind of load is in progress.

Comment 19

[hreiser]

The problem still appears in Firefox 22.
The timout in our Refresh-tag is been ignored:
<meta http-euiv="Refresh" content="900"; URL=logout.xhtml" />

Therefore the user who clicks "Allow" is logged out directly.

In my view the solution to warn immediately and to redirect after the timeout is not the best.
Many users don't understand the delay between Click on "Allow" and Redirect.

I my opinion the message should appear at the end of the timeout.

Comment 20

[Daniel Kabs, reporting bugs since 2002]

I observed the same problem using my bank's website for online banking. The banking website uses the meta REFRESH element to implement an auto log-out feature. After a timeout of 600 seconds, the meta Refresh elements redirects to a page that logs the user out. The first time I saw the information bar appear, I clicked the "Allow" button and was logged out.

To fix this, I suggest that in case a timeout > 0 is used:
- Instead of an allow button, two buttons are be offered: "Go later", "Go now"
  - If the user wants, e.g., to use the describe auto-logout feature, he clicks "Go later".
  - On other pages, the user might want to press "Go now", e.g., to start a download immediately.
- the timeout value is displayed and 
- the redirection target URL (see bug #459373)
- optionally: the timeout value is counted down and if it reaches 0, the information bar reverts to the "one button" format. :-)