Skip meta-refresh pages on "Back Arrow" (a keystroke to do that)

NEW
Unassigned

Status

--
enhancement
19 years ago
2 years ago

People

(Reporter: jce2, Unassigned)

Tracking

({access})

Trunk
access

Firefox Tracking Flags

(firefox35 affected, seamonkey2.32 affected)

Details

(Reporter)

Description

19 years ago
This would get rid of a MAJOR annoyance, getting stuck in a long stream
of pages that keep meta-refreshing to the next page, so you have to keep
hitting back arrow as fast as you can to get out of the stream.

Create a keystroke/mouse combination (like Shift + Click on back arrow)
that moves you back to the last page that did NOT send you to the
next page via Meta-Refresh.

This should be an OPTION, (if it becomes the default, then there should
be a way to move to the previous page, even if it DID send you to the 
next page via meta-refresh.)

The difficulty of implimenting this feature depends on whether mozilla
handles a meta-refresh differently then any other navigation operation.

Comment 1

19 years ago
Good idea, but let's consider implementation a little later ...
Target Milestone: M20

Comment 2

19 years ago
Moving all UE/UI bugs to new component: User Interface: Design Feedback
UE/UI component will be deleted.
Component: UE/UI → User Interface: Design Feedback

Updated

19 years ago
Component: User Interface: Design Feedback → XPApps

Comment 3

19 years ago
I can easily make this always keep pages with meta refresh out of the list, but 
doing it sometimes as you suggest isn't easy.  I would actually lean towards 
doing the always replace the meta refresh page in history.  Thoughts?
Status: NEW → ASSIGNED

Comment 4

19 years ago
The RFE in this bug sounds great. Those who say that the "Go" button is useless
should think again :-) It helps to get around this meta-refresh annoyance.

Travis, following your line of thoughts, rather than overwriting, what about
setting a flag on the entries loaded with meta in the history list, and then
when the keystroke combination is used, jump pass all the flagged entries?
This could work for both the Back and Forwoard buttons.

Comment 6

18 years ago
meta refresh content="0" pages should definitely be skipped when using the back
button. For example: http://www.mtmis.com/mail

I suggest that when this feature is implemented, its behavior be made the
default (to skip past a meta-refresh page), but not to delete meta-refresh pages
from the history all together. That way if you wanted to get to one of them, you
could still use the drop-down menu on the back button to do so.

Updated

18 years ago
QA Contact: elig → sairuh
Summary: {ENHANCEMENT] Skip meta-refresh pages on "Back Arrow" (a keystroke to do that) → [RFE] Skip meta-refresh pages on "Back Arrow" (a keystroke to do that)

Updated

18 years ago
Target Milestone: M20 → mozilla1.0

Comment 7

18 years ago
Is there a way that we could have the browser not interpret meta-refresh tags if
the user backs up to a page? This problem would then be solved without the
guessing that would be involved in actually fixing this bug the way it was
originally reported.

Comment 8

18 years ago
linux x86 2001-03-14-08

I no longer see this problem - it appears to be fixed.
Can anyone else confirm this?

Comment 9

18 years ago
-> radha, and nulling out the milestone so she can set it appropriately.
Assignee: valeski → radha
Target Milestone: mozilla1.0 → ---
Status: NEW → ASSIGNED
Target Milestone: --- → Future

Comment 10

17 years ago
Adding access keyword - this makes things very difficult for mobility impaired
users.
Keywords: access

Comment 11

17 years ago
I think going back to a meta-page is rarely wanted, and I would suggest it not a
blatantly visible part of the standard Mozilla UI.  I would prefer the duplicate
meta-pages be removed from the "back" button menu, and only available via a
special command, say a special entry in the "Go" menu.  Otherwise it doesn't
take long to get a Back menu filled with meta-pages.  For developers, it might
be useful to have a preference that restores meta-pages to the history list.

Does any other browser keep meta-pages in the history?

Comment 12

17 years ago
*** Bug 102417 has been marked as a duplicate of this bug. ***

Comment 13

17 years ago
IMHO, if the page has a refresh of 0, which should send to to "another" page
without waiting, it should not be in the back-button history. If the pause is
longer, then that means the page most likely has some sort of message, like
We've Moved or something like that, and it should stay in the history.

Now, if a page refreshes to itself, only one instance of the page should be in
the history. But I think thats the way it is already anyway.

I think the above should be the default, with maybe an option somewhere to
enable pages to stay in the history regardless of refresh.

Comment 14

17 years ago
I disagree.  The meta-refresh pages I know of are mainly sports scores and auto-
forwarding pages.  Why would I want to go back to an auto-forwarding page?  
It'll just forward me again.  Meanwhile, sports-related ones generally update 
with new info that includes all the old, so there's no need for the old page.  
And no, this does not leave one instance in the history, I can end up with 
dozens.

Comment 15

17 years ago
That's the same thing I was trying to say.

1. Immediate-Auto-Forwarding pages dont get saved anywhere.
2. If the pause is longer, put it in the history (toggable option)
   This is because maybe a page has a message, like "Site Is No Longer Up"
   and maybe I want to go back and read the message if I didn't get enough
   time before. Of course, this could be toggable.
3. Pages that refresh themselves keep one instance in the history. Just like
   any other page. That way you could move back and forth between nba and
   nfl scores.

Comment 16

17 years ago
There is still a problem with same page refreshes getting put in the history. 
If the page refreshes to an anchor, say like <meta HTTP-EQUIV="Refresh" CONTENT="45;
URL=#NOW"> (taken from the Washington Post at
http://discuss.washingtonpost.com/wp-srv/zforum/01/auto_brown1022.htm ) it still
is constantly put into the history.

Comment 17

17 years ago
This is one of my biggest gripes with Mozilla right now.  If I (accidentally)
leave my browser on a page that self-reloads (such as cnn.com) and wander away,
it happily reloads the page over and over, filling my history.

Netscape and IE don't add these meta-refreshed pages to the history, why does
Mozilla?

Comment 18

17 years ago
Both Opera and IE6 allow you to turn off META REFRESH via a pref.
(Allow automatic redirection : true/false)

Opera and Lynx not only let you turn off META REFRESH, they generate HTML
linking to the refreshed page, so you can refresh it manually.

See: http://www.w3.org/TR/WCAG10-CORE-TECHS/#auto-page-refresh

Specifically:

Both checkpoint 7.4 and checkpoint 7.5 address problems posed by legacy user
agents. Newer user agents should disable refresh and substitute a link to new
information at the top of the page.

Updated

16 years ago
Summary: [RFE] Skip meta-refresh pages on "Back Arrow" (a keystroke to do that) → Skip meta-refresh pages on "Back Arrow" (a keystroke to do that)
Product: Core → Mozilla Application Suite
Assignee: radha → jag
Status: ASSIGNED → NEW
Priority: P3 → --
QA Contact: bugzilla
Target Milestone: Future → ---

Comment 19

9 years ago
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED

Comment 20

9 years ago
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 21

9 years ago
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 22

9 years ago
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 23

9 years ago
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 24

9 years ago
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 25

9 years ago
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 26

9 years ago
It would still be nice to easily escape from pages that 'break' the back button.

Comment 27

4 years ago
It is obvious that there is not much user-interest in this issue.
Can't remember to have seen that problem ever.
Please feel free to reopen this bug if you can contribute Websites still causing the reported problem so that the problem will be reproducible.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WORKSFORME

Comment 28

4 years ago
Hm, I thought some moments and may be I did not all aspects of the problem. currently I only remember Web pages where it is completely impossible to get back to previous page by Back-button, but I think I also should be able to find public web pages where effect that "Back" only is successful with Back-automatic-fire.

Comment 29

4 years ago
I think I can contribute a step by step instruction, reproducible for users with last.fm account:
1. Go to <https://encrypted.google.com/> in a new Browser window
2. Replace URL by "http://www.lastfm.de/music/Bess+Rogers?setlang=de" ► [Enter]
   » Artist Info will appear
3. Click Login button at top right of the page and log in 
   » Artist Info will reappear after login has been done
4. Try to get back to google by clicking Browser-'Back' button
   Expected: after few clicks you will be back on google page
   Actual: you can click Browser-'Back' button as often as you want and as quick as you can,
           Browser-'Back' button will not become greyed out after maximum number of steps back
           google page can not be reached
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: WORKSFORME → ---

Comment 30

4 years ago
Works better in IE11 when you try Comment 29 steps:
In step 4 do a Browser-'Back' button every 20 seconds: after 3 clicks you will be back at google page.
Status: REOPENED → UNCONFIRMED
Ever confirmed: false

Comment 31

4 years ago
New due to comments 29, 30
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

4 years ago
tracking-seamonkey2.32: --- → ?

Comment 32

4 years ago
Same problem in FF 35.0.1

Workaround: clicking smal downarrow at right end of Browser-'Back' button will show a list of pages visited in this TAB, clicking "Google" in step 4 will work fine.

I can't tell whether this problem already has been reported for FF.
status-firefox35: --- → affected
status-seamonkey2.32: --- → affected
tracking-seamonkey2.32: ? → ---
Assignee: jag-mozilla → nobody
You need to log in before you can comment on or make changes to this bug.