Open Bug 213467 Opened 21 years ago Updated 2 years ago

if a bookmark fails to load, try to find a previous redirect target for it in history

Categories

(Firefox :: Bookmarks & History, enhancement, P5)

Product:
Firefox
Component:
Bookmarks & History
Type:
enhancement

Tracking

()

People

(Reporter: paul.stanton, Unassigned)

References

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030516 Mozilla Firebird/0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030516 Mozilla Firebird/0.6

Web administrators setup 301 responses for a very good reason. To PERMANENTLY
redirect traffic to a new location.
The HTTP spec states: 301 Permanent redirect: MUST follow, SHOULD check new
location thereafter.
My interpretation in the bookmark scenario is that the bookmark should update to
the new locatio provided in the header.

Reproducible: Always

Steps to Reproduce:
1. create a bookmark to http://wanto.f2o.org/links.php
2. use bookmark
3. bookmark takes you to http://wanto.f2o.org/index.php due to 301 response

Actual Results:  
bookmark references http://wanto.f2o.org/links.php

Expected Results:  
bookmark references http://wanto.f2o.org/index.php
This is no bug, but an enhancement request. Confirming it as such.
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
See also bug 8648, same bug for seamonkey.
taking QA contact, sorry about the bugspam
QA Contact: asa → mconnor
Setting blocking?1.0 because I believe it's the little touches like these that
will help make Firefox 1.0 be the best browser ever :-)

Whether it makes 1.0 or not, I would like a notification of any changes (maybe
even a prompt?). Silent changes would be bad.
Flags: blocking-aviary1.0?
Not something that's going to be a priority.  If we were going to do this, it
would be interaction-free or not at all, but given that the seamonkey bug is
getting on five years old without a fix, I doubt its trivial.
Flags: blocking-aviary1.0? → blocking-aviary1.0-
OK fair enough - but the seamonkey bug seemed to go off-topic quite quickly
(timeout problems with OLD _automatic testing_ code?).

My interpretation of this enhancement request is that it would only be triggered
when the bookmark is used - so looking at only the usual few seconds delay for a
response. So it would be a lot easier to implement...
my expected behaviour is that when the browser receives a 301 (and a 301 is
actively sent by the webserver ie: no delay, no timeout) the bookmark is updated
and the user is taken to the new location. i don't see how "few seconds delay
for a response" or "timeout problems" are at all relevant.

also, it is a very trivial enhancement and does stop anyone doing anything so i
don't get why it would ever block a release. Its a simple 'perfect world' way of
handling the 301 http response.
i meant "it is a very trivial enhancement and DOESN'T stop anyone doing anything"
Interesting timing, I was just going to suggest this...

I agree that this should be done only when a bookmark is followed. That keeps
the scope small enough, and this would be a nice touch to help keep bookmarks
current behind the scenes.

As noted in the original report, the HTTP spec does recommend doing this, though
it's a SHOULD and not a MUST.
-> vlad.
Assignee: p_ch → vladimir
Very tiny chance I'll get to this before 1.0; this also affects favicons, as
bookmarks to sites which are 301's won't get the favicon updated (since the
bookmark URL doesn't match the site URL, see end of bug 252288)
Status: NEW → ASSIGNED
Blocks: 252288
Blocks: 246833
Blocks: 262161
No longer blocks: 262161
needs aviary landing keyword
This has nothing to do with aviary-landing.  This has never been implemented,
let alone regressed due to landing aviary branch on trunk.
It would be impressive if Mozilla took the lead on full HTTP support. Not just
"good enough", but stepping up to be the first browser to offer meaningful
support for "205 Reset Content" (reset data entry form), "301 Moved Permanently"
(offer to update bookmark, or do it automatically), and "410 Gone" (offer to
delete bookmark).

At worst, this is a prestige issue, so competitors have to continue trying to
catch up. At best, users and authors will more seriously leverage these features.
See http://www.nevon.net/nevon/2005/04/rss_feed_hijack.html for an example of
why we don't want to silently rewrite bookmarks based on 301s: if you connect to
a hotel's misconfigured proxy, then open your "All my most important
work-related bookmarks" folder in tabs, you do not want them all rewritten to
the proxy's "pay me first" page without asking. I know the
blocked-install/-popup/missing plugin infobar is just the new
dialog-in-your-face, but at least it would be a little more tolerable way of
asking for permission to rewrite the bookmark.
*** Bug 312148 has been marked as a duplicate of this bug. ***
-> Places, if ever.
Assignee: vladimir → nobody
Status: ASSIGNED → NEW
Component: Bookmarks → Places
QA Contact: mconnor → places
Comment 15 gives an excellent argument. There appears to be some anecdotal evidence of misconfigured proxies that give permanent redirects. More worringly is the ability of malicious proxies to mess up your bookmarks. This is especially bad considering how many people use random WiFi hotspots they find around town. I hope we can agree that we shouldn't ever automatically change bookmarks.

Furthermore, I agree with Mike above that any implementation should be interaction free. Even the infobar is too heavyweight for me. There are a *lot* of permanent redirects, and you'll get it often whenever you type in a bookmark URL, which would be annoying.

Here's one suggestion I could live with: Places will keep track of redirections. If you follow a bookmark and get a 404/410, we might look in history to see if the page with an error previously redirected to something. *Then* modally offer to try to change the bookmark. Since the page is gone anyway, the interruption won't be an extra annoyance, and you won't ever have to see all the common ones like "http://amazon.com/" redirecting to "http://www.amazon.com/exec/obidos/subst/home/home.html" This would need an experienced volunteer to implement since it would be non-trivial and it's not on anybody's roadmap.
Assignee: nobody → brettw
Priority: -- → P5
I think this bug should not be fixed.

The bookmarks does belong to the user and the browser should not change them without permission.

_If_ this is going to be fixed, there should be information/confirmation-dialog that tells the user that this happened.

Experienced users will not like it if the browser is 'messing up' their bookmarks.
Unexperienced users may be confused because they have created a bookmark to "http://amazon.com" and when checking this bookmark, the url is "http://www.amazon.com/exec/obidos/subst/home/home.html".

There is an other possible problem with this. Assume, the user has bookmarked "http://amazon.com" and amazon redirects to "http://www.amazon.com/exec/obidos/subst/home/home.html", so firefox changes the bookmark, too.
If amazon.com now moves their index page to (for example) "http://www.amazon.com/index/index.html" and forgets to redirects from the old position, then the user may get a 404 error. If firefox would leave the bookmark as it it, this would not happen.
> Experienced users will not like it if the browser is 'messing up' their
> bookmarks.

Experienced users will not like it if the site is 'messing up' their bookmarks either.
If a site is using 301 redirects, they are saying that A is being permanently replaced by B.  If they later put a redirect from A to C, without also redirecting B to C, they're doing something extraordinarily stupid.  I'm not concerned with random misuse of the HTTP spec, in general.
(In reply to comment #21)
> If a site is using 301 redirects…

Which is not Amazon since they use 302 redirects which makes Jonathan's scenario purely fictional (until we find a site that does redirect to its index page using 301 responses).
But I do also think that there should be some kind of feedback on whether the URL of a bookmark should be changed. Maybe this can be put into the information bar on top (the one that does also inform the user that a popup has been blocked).
I think this bug is definitely a WONTFIX. But since I'll get flamed for marking it as such, I'll just forget about it. Even if you think it should be changed, I don't see any chance of this getting implemented in places any time soon.
Assignee: brettw → nobody
It both must be interaction-free, and must not be automatic: "uiwanted".

The only UI I can imagine, adding some visual indication that a bookmark is redirecting, with a management dialog to approve which redirecting URIs to change, sounds so much like an extension that ~200 people would use that I'd be inclined to verify your wontfix.
Keywords: uiwanted
This is the UI you want:

 - load bookmark
 - detect 301 redirect
 - redirect browser
 - pop a browsermessage saying "This page has changed address, update bookmark?"

Rationale: non-modal, not in the way, tells the user what happened. All due respect to mconnor and brettw, but the user's bookmarks are the property of the user, and while we should offer to do the helpful thing, until we can be certain that it is the right thing (see comment 15) then we shouldn't be doing *anything*.

(removing uiwanted)
Keywords: uiwanted
(In reply to comment #25)

Are you suggesting something then like the pop-up blocker, or how Greasemonkey does offers to install userscripts?
A user should be able to set how many days of redirects the browser will tolerate before it changes the bookmark. That way it can be set to enough days to avoid hijacking (#15), or -1 days to prevent the browser changing the user's bookmarks (#19).

Two birds with one stone?
(In reply to comment #22)
> (In reply to comment #21)
> > If a site is using 301 redirects…
> 
> ...until we find a site that does redirect to its index
> page using 301 responses)...

http://en.wikipedia.org/ is a 301 redirect to http://en.wikipedia.org/wiki/Main_Page

My guess is that all of the Wikimedia Foundation projects use it.

MediaWiki could be fixed.

I don't believe that MediaWiki can fairly be considered at fault in this situation. That said, while updating bookmarks to homepages (like MediaWiki's) is useful, the major application of this feature is when a website reorganizes its structure and uses 301's to direct visitors to the new locations or 410's to indicate pages that have disappeared completely (see also bug 301144).
Summary: bookmark to page which returns 301 should update to new location → bookmark to page which returns 301 should ask user if he wants to update to new location
Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h".

In Thunderbird 3.0b, you do that as follows:
Tools | Message Filters
Make sure the correct account is selected. Click "New"
Conditions: Body   contains   places-to-b-and-h
Change the action to "Delete Message".
Select "Manually Run" from the dropdown at the top.
Click OK.

Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter.

Gerv
Component: Places → Bookmarks & History
QA Contact: places → bookmarks
(In reply to comment #25)
> This is the UI you want:
> 
>  - load bookmark
>  - detect 301 redirect
>  - redirect browser
>  - pop a browsermessage saying "This page has changed address, update
> bookmark?"
> 
> Rationale: non-modal, not in the way, tells the user what happened. All due
> respect to mconnor and brettw, but the user's bookmarks are the property of the
> user, and while we should offer to do the helpful thing, until we can be
> certain that it is the right thing (see comment 15) then we shouldn't be doing
> *anything*.
> 
> (removing uiwanted)

It's a good way to implement this, I only add that the the info window should show the old and new URI, and the responses to "This page has changed address, update bookmark?" should be: YES, NO, NEVER

NEVER had to be saved in as bookmark option.
I'm morphing the bug a bit, because I think "prompt the user" is a no-go (as mconnor mentions in 5). But since we track redirects in History, we could try to be smart about changing a bookmark's target when the bookmark target no longer loads correctly. Still may be WONTFIX, though.
Summary: bookmark to page which returns 301 should ask user if he wants to update to new location → if a bookmark fails to load, try to find a previous redirect target for it in history
Blocks: 275255
Priority: P5 → --
ux-discovery keyword
(In reply to Worcester12345 from comment #34)
> ux-discovery keyword

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