Browser History:Redirects

Rationale

The current history implementation does not handle redirects well. If you visit http://google.com, you will get redirected to http://www.google.com. The redirect page does not have a favicon or a title, and only clutters history views with unhelpful information.

This type of problem will be much more significant when planned enhancements are made with the places system. For example, if there is an easy-to-use bookmark button that shows the bookmark state of the current page, this button will be broken if a bookmark redirects. You will also not get proper favicons associated with the bookmark, and any notes or other annotations on the page will be ambiguous.

We will therefore need to pay special attention to redirects and provide some type of canonicalization to URLs to determine if they are bookmarked or what we should display in history views.

Note that this problem is not generally solvable. First, some types of redirects are not detectable as redirects, such as navigations done by JavaScript on the web page. Second, it is always possible to construct cases where it is not well-defined what the correct answer is. For example, different combinations of redirect destinations changing temporally, multiple pages redirecting to the same page, multiple levels of redirects, and annotations associated mean in some cases it is not well-defined what set of data should be shown for the page. As a result, the goal is to do something that catches reasonable cases of redirection, and doesn't give ansers that are clearly wrong.

Scenarios

Link Permanent Redirect

This case happens when the user follows a link that is redirected by one or more 301 (moved permanently) redirects.

This is the easy case, the canonical URL is the redirected version. All interesting information such as title and favicon are stored on the destination, we should just show the destination in history.

Bookmark Permanent Redirect

If you follow a bookmark and get a permanent redirect, should the bookmark be updated automatically? But, this might be annoying to some users. See bugs 103610, 8648, and 213467. There are several choices:

• Pick the second as canonical and update the bookmark. This could occationally be annoying if the user actually wants to see the simpler bookmark and it keeps getting changed behind their back.

• Pick the second as canonical, and don't update the bookmark. We only show the destionation URL in history, and show it as bookmarked. This could be potentially confusing in some cases, since the user may not recognise the URL. This problem will always be present, however, since they if they visit any page equivalent to a bookmarked page, they will see it as bookmarked.

• Pick the source URL as bookmarked and use the destionation's attributes such as title and favicon. In many cases, this will yield the simplest, most understandable history. In other cases, it could be annoying. It might also be difficult or slow to implement since attributes will have to be moved around and kept track of.

Typed Permanent Redirect

This is probably the most common case. The user types a common URL, such as "http://google.com/" or "http://amazon.com/" and is 301 (moved permanently) redirected to "http://www.google.com/" or "http://www.amazon.com/exec/obidos/subst/home/home.html".

The approaches, advantages, and drawbacks will be the same as for the bookmarked case, except we don't need to worry about updating the bookmark.