I found this in an old newsgroup message "proposed bookmark management features" in n.p.m.ui on 26 Oct 98, and I fully agree, so I'm posting an RFE. This is what the poster had to say: --- I propose a new feature for all webbrowsers. Actually two: 1) When going to a bookmark, if the site is not up, ask the user if they want to: a) remove this bookmark b) mark it as being down last X attempts c) do not remove this bookmark d) do not remove this bookmark; don't ask this question again for this url d) do not remove this bookmark; don't ask this question again ever 2) When going to a bookmark to a page that uses the META tag to do an HTTP redirect, ask the user if they want to: a) update the last bookmark they went to to this new address (useful since most webpages move at one time or another) b) do not update; don't ask this question again for this url c) do not update; don't ask this question again ever These 2 features would make it so that one would have to "organize bookmarks" much less often. The main organization function of organizing your bookmarks is to create an intuitive heirarchy of bookmarks; we should not have to go into that menu just to remove dead links and update pages that have moved. --- I've wanted the second myself for a while - I believe HTTP distinguishes between temporary and permanent redirects, so only the latter should be handled this way. Also, it would be useful to write in a new address as an option for the first one.
Best would be a pref to choose and option or prompt the user.
Move to M20.
The second sounds VERY cool. Prompting when we recieve a 'Permanently Moved' return is so useful and obvious I can't believe it wasen't done by browsers long ago. If i had and free browser votes, I'd add one. =) This would even encourage people to use this HTTP feature more, instead of making the 'This page has moved, please update your bookmarks' page. The first suggestion, however, might get VERY annoying. A site being 'down' is too common an occurance to throw dialogs at the user, especially when theres a > 50% probability they will want to take no action on it.
You could put some sort of threshhold on it appearing, either time or number-of-visits based. You'd still want some way to easily access these options though - perhaps a "Remove Current Page From Bookmarks" option is in order.
Move to "Future" milestone.
I'm out of votes, but I also wanted to say this is a great idea.
Since Don has left, Vishy is taking his bugs in bulk, pending reassignment. thanks, Vishy
Netscape Nav triage team: this is not a Netscape beta stopper.
bookmarks, => me.
Accepting, leaving priority as-is but adding status whiteboard glitter.
Paul Chen is now taking Bookmarks bugs. For your convenience, you can filter email notifications caused by this by searching for 'ilikegoats'.
*** Bug 22714 has been marked as a duplicate of this bug. ***
HTTP 1.1 has the following to say about '301 Permanently Moved': Clients with link editing capabilities ought to automatically re-link references to the Request-URI to one or more of the new references returned by the server, where possible. We should also support '410 Gone', and offer to remove the bookmark. In the dialogue, we must make clear that this is different from a page just not found (i.e. a 404 error) -- the page is removed, and will *not* reappear, not here, not anywhere. Also note that we need to handle multiple redirects. For a simple test case of 301 redirection, you could try: http://home.no.net/~huftis/mozilla.html which redirects to: http://home.no.net/huftis/mozilla.html which redirects to: http://home.no.net/huftis/mozilla/ which redirects to: http://home.no.net/huftis/nynorsk-programvare/mozilla/ A bookmark pointing to: http://home.no.net/~huftis/mozilla.html should therefore be changed to: http://home.no.net/huftis/nynorsk-programvare/mozilla/
mass reassign of pchen bookmark bugs to ben
adding self to cc list
*** Bug 157999 has been marked as a duplicate of this bug. ***
A problem with previous validate-bookmarks features is that the code assumed a far faster internet connection than most dialup users have. The slow responses of the queries to bookmark entries caused most of them to be reported as no longer valid. This timing problem could also occur in a bookmark updating feature running on a slow dialup connection.
When a 404, 410 or 'unable to find host' situation is encountered on a bookmark click, we could also give the user the option of checking for the page within the Internet Archive (archive.org). I know there have been several occasions when an bookmark has gone missing that I've checked archive.org to get an archived version. Perhaps we could offer to link to Google's archive as well (though it isn't quite as long-term).
The idea proposed in comment #18 should be a separate bug.
*** Bug 23212 has been marked as a duplicate of this bug. ***
*** Bug 213128 has been marked as a duplicate of this bug. ***
This feature request is almost 4 years old now.. does anyone know what's holding it up ? Is it simply that nobody has offered to write the code ?
>Is it simply that nobody has offered to write the code ? correct
See also bug 213467, same bug for firebird.
*** Bug 227536 has been marked as a duplicate of this bug. ***
The solution would be very simple---make the timeout value selectable by the user so it can be set according to how fast the user's connection is.
Often the delay in accessing URLs for validation is caused by slow DNS servers, not by the connection speed. DNS servers seem to have highly variable response times depending on their load at the moment. I'm sure noticing slow DNS service today.
Setting this to work on a timeout is a bad idea, and would result in sites being removed from users' bookmarks if their server goes down for a few hours. It should be based solely on HTTP error messages that are returned from the server, like "301 Moved Permanently".
What about when the server is down forever? There could be a message like: "The site x.y was down for 2 weeks. Do you wan't Firefox to remove it from your bookmarks? [Yes] [No] [Stop bugging me]"
I think that Ross Shannon is right. Only HTTP 301 codes, should be handled this way.
The HTTP spec defines very specific behavior for each code. Status codes of note include 301, 400, and 410.
I would just like to revive the discussion on this topic. I actually thought that I had already seen this feature in one of the older Mozilla (or even Netscape) versions: it was not automatically but there was a tool in the bookmarks window that said something like "verify bookmarks" and then the browser would try one bookmark after the other and mark the ones which did not exist anymore. I would find this a very very useful feature. I have a rather huge bookmark file and it's a large amount of work to test all of these and to either update links or throw them out. In my opinion this is really an automation task for which computers were designed. I'm not a programmer myself, at least not for these kinds of tasks, but perhaps somebody in the SeaMonkey team might take it up ....
This bug is not about scanning your bookmarks folder and updating en masse. It's about updating bookmarks as you follow them.
So, should I open a new bug for "updating en masse" ?? Oliver
I believe that's bug 171467.
(In reply to comment #36) > *** Bug 171467 has been marked as a duplicate of this bug. *** I do not agree with this. Bug 171467 is a bug for "updating en masse". Bug 8648 is a bug for "updating bookmark(s) on the fly".
At least second part of this bug looks still valid rfe
What is keeping the Mozilla developers not to try to enhance User Experience by adding this feature to the browser ?
Forgot to add. This request for the valuable enhancement is already 15 years young
I have created an add-on to solve this bug. https://addons.mozilla.org/en-US/firefox/addon/bookmark-301-updater/ There have been concerns raised about the security of this however. For example, a man-in-the-middle can silently rewrite any bookmarks that the victim may have, causing future browsing to go directly to the attacker-chosen URL, rather than the intended URL.
Could you explain a bit in more detail what this add-on does precisely ? Thanks in advance Concenring security, that's why I think, just checking for Error404 and flagging failing bookmarks and giving the user the possibility to simply remove all failing bookmarks (or put them into a folder to check manually) as suggested in bug 171467 would be much saver.
The extension watches for redirects that the browser follows. If they have status code 301 (ie, permanent), it'll search all bookmarks for the old URL, and update them with the new URL. There's no current handling for 404s or any other status codes. Also, HSTS upgrades aren't detected by the extension, as these don't generate a 301 from the server. (They happen client side.)