This is a tracking bug for planning and implementation of new feature work for Netscape's MachV project. All plan/spec/design documents should be posted on mozilla.org and discussed in the appropriate newsgroup(s), not here. New dependency bugs will be created for any subtasks. Please use this bug only for discussing the plan itself, or to add links to any pertinent discussion elsewhere. Proposed requirements: * When a user hits a bookmark and finds that the page has moved, prompt user with a dialog asking them if they'd like to update their existing bookmark. * Choosing yes automatically updates bookmark to the page they are being redirected to. Current engineering plan: not sure if this is technically feasible or not, unless we assume moved pages have META refresh. Assuming this is the intent of the feature, 4 days including notification UI. Currently assigned to @netscape.com for planning/design. Implementation estimate: 4 days This is still too vague, needs spec/design and review/approval.

p3/096 (for planning, implementation can wait til 097), blocks 102472

->bookmarks

"not sure if this is technically feasible or not, unless we assume moved pages have META refresh" Of course, we shouldn't assume that all pages with meta refresh are pages that have moved. Would it be possible to search for strings such as "This page has moved" or "Update your bookmarks" in the page? If both a meta refresh tag and an appropriate string are found, we can be pretty confident that the page has moved. The best thing would be if there was a specific meta tag for moved pages. Something like: <meta name="moved" content="http://www.newlocation.com/">

Paul Chen is now taking Bookmarks bugs. For your convenience, you can filter email notifications caused by this by searching for 'ilikegoats'.

Joe Hewitt has volunteered to take this.

*** Bug 106320 has been marked as a duplicate of this bug. ***

There is a seperate bug for updating bookmarks when the server returns the code for Permanently moved (and removing them for 404s). There's no other situation the user should be asked, unless we invent a new <meta> type tag to allow this to be triggered without server support. I suggest this is duped to 8648.

This targetted for M101. Should we remove it from blocking Bug 102472, since its current target is outside the dev window for the next release?

->future

Is this bug different in any way from bug 8648?

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

> Is this bug different in any way from bug 8648? Doesn't look like it. The Firefox bug was also duped to 8648.