Last Comment Bug 213467 - if a bookmark fails to load, try to find a previous redirect target for it in history
: if a bookmark fails to load, try to find a previous redirect target for it in...
Status: NEW
:
Product: Firefox
Classification: Client Software
Component: Bookmarks & History (show other bugs)
: unspecified
: All All
: -- enhancement with 38 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: Marco Bonardo [::mak]
Mentors:
: 312148 (view as bug list)
Depends on:
Blocks: 275255 246833 255085
  Show dependency treegraph
 
Reported: 2003-07-22 17:11 PDT by paul stanton
Modified: 2016-02-01 08:04 PST (History)
24 users (show)
mconnor: blocking‑aviary1.0-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description paul stanton 2003-07-22 17:11:17 PDT
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
Comment 1 Simon Paquet [:sipaq] 2003-07-23 02:36:37 PDT
This is no bug, but an enhancement request. Confirming it as such.
Comment 2 Jesse Ruderman 2003-07-26 04:51:46 PDT
See also bug 8648, same bug for seamonkey.
Comment 3 Mike Connor [:mconnor] 2003-07-28 11:17:26 PDT
taking QA contact, sorry about the bugspam
Comment 4 Doug Wright 2004-07-18 08:50:59 PDT
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.
Comment 5 Mike Connor [:mconnor] 2004-07-18 09:30:17 PDT
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.
Comment 6 Doug Wright 2004-07-18 11:14:47 PDT
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...
Comment 7 paul stanton 2004-07-18 15:58:05 PDT
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.
Comment 8 paul stanton 2004-07-18 15:59:21 PDT
i meant "it is a very trivial enhancement and DOESN'T stop anyone doing anything"
Comment 9 Kelson 2004-07-20 17:16:00 PDT
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.
Comment 10 Mike Connor [:mconnor] 2004-07-20 17:38:44 PDT
-> vlad.
Comment 11 Vladimir Vukicevic [:vlad] [:vladv] 2004-07-30 17:54:34 PDT
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)
Comment 12 Worcester12345 2004-12-23 23:47:44 PST
needs aviary landing keyword
Comment 13 Mike Connor [:mconnor] 2004-12-24 00:54:01 PST
This has nothing to do with aviary-landing.  This has never been implemented,
let alone regressed due to landing aviary branch on trunk.
Comment 14 Brian Lalonde 2005-04-25 10:35:49 PDT
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.
Comment 15 Phil Ringnalda (:philor) 2005-05-01 11:16:26 PDT
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.
Comment 16 Phil Ringnalda (:philor) 2005-10-12 09:03:08 PDT
*** Bug 312148 has been marked as a duplicate of this bug. ***
Comment 17 Mano (::mano, needinfo? for any questions; not reading general bugmail) 2005-12-27 03:05:08 PST
-> Places, if ever.
Comment 18 Brett Wilson 2005-12-28 16:00:15 PST
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.
Comment 19 Jonathan Haas 2006-02-19 04:02:01 PST
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.
Comment 20 Trejkaz (pen name) 2006-02-19 17:59:32 PST
> 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.
Comment 21 Mike Connor [:mconnor] 2006-02-19 18:51:30 PST
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.
Comment 22 Raphael Schweikert 2006-02-20 00:29:55 PST
(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).
Comment 23 Brett Wilson 2006-05-12 09:52:31 PDT
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.
Comment 24 Phil Ringnalda (:philor) 2006-05-12 10:30:58 PDT
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.
Comment 25 Mike Beltzner [:beltzner, not reading bugmail] 2006-05-26 09:09:46 PDT
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)
Comment 26 Shawn Wilsher :sdwilsh 2006-05-26 09:27:39 PDT
(In reply to comment #25)

Are you suggesting something then like the pop-up blocker, or how Greasemonkey does offers to install userscripts?
Comment 27 Geoff Lankow (:darktrojan) 2006-07-06 04:57:25 PDT
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?
Comment 28 George Macon 2007-10-24 11:39:29 PDT
(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.
Comment 29 Trejkaz (pen name) 2007-10-24 21:57:09 PDT
MediaWiki could be fixed.
Comment 30 George Macon 2007-10-25 11:21:21 PDT
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).
Comment 31 Gervase Markham [:gerv] 2009-11-26 07:26:41 PST
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
Comment 32 Vinagre 2010-06-09 10:51:06 PDT
(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.
Comment 33 :Gavin Sharp [email: gavin@gavinsharp.com] 2013-03-15 09:58:01 PDT
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.
Comment 34 Worcester12345 2016-02-01 08:04:56 PST
ux-discovery keyword

Note You need to log in before you can comment on or make changes to this bug.