Open Bug 417770 Opened 12 years ago Updated 9 months ago

META REFRESH redirect warning appears immediately instead of when timer fires

Categories

(Core :: DOM: Navigation, defect)

defect
Not set

Tracking

()

People

(Reporter: dpfender44, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(3 files, 1 obsolete file)

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.
This only happens if you have checked "Warn me when sites try to redirect or reload the page" in Tools > Options > Advanced > General, right?
Blocks: 83265
Summary: META REFRESH Timer problem → META REFRESH redirect warning appears immediately instead of when timer fires
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.
What do you guys think?
OS: Windows XP → All
Hardware: PC → All
Version: unspecified → Trunk
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.

Would it make sense to simply relabel the button from "Allow" to "Go now"?
It would be more "accurate" but not functionally any better.
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
Attached file 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).
Component: General → Document Navigation
Product: Firefox → Core
QA Contact: general → docshell
Attached patch Patch v1 (obsolete) — Splinter Review
Move RefreshAttempted() from nsIRefreshURI::RefreshURI() to ForceRefreshURIFromTimer(). And s/ForceRefreshURIFromTimer/RefreshURIFromTimer/, since it will no longer *force* to refresh URI.
Attached patch Patch v1.1Splinter Review
Fix comments about aTimer were dropped.
Attachment #639002 - Attachment is obsolete: true
Attachment #639006 - Flags: review?(bugs)
Comment on attachment 639006 [details] [diff] [review]
Patch v1.1

This needs tests.
Attachment #639006 - Flags: review?(bugs) → review+
I agree this bug needs a testcase, but I'm not too sure exactly what to be tested.
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.
Attachment #639006 - Flags: review+ → review-
(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?
Well, then we need some new API.
The problem is that there can be other onRefreshAttempted implementations than just the one
for the UI.
> 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).
Well, docshell could expose what kind of load is in progress.
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.
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. :-)
You need to log in before you can comment on or make changes to this bug.