613126 - Reopened tabs not stored in history

Status: ASSIGNED

(Firefox :: Session Restore, defect)

Description

[james.carlyleclarke]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12

This is perhaps not exactly a bug, but I believe the behavior should be changed, or there should be an option to allow whichever behavior we want.

As far as I can see, the History system stores pages when they are opened, and maybe when they are closed (but not if the browser crashes). The 'Recently Closed Tabs' system stores them when they are closed (perhaps not if the browser crashes), but has limited items.

I often keep lots of tabs open for a long time (eg 2 weeks, a month) across browser restarts. Sometimes during that time I clear my browser history.

If I (in chronological order)
1) Open a tab
2) clear the history
3) have a browser crash that (for whatever reason, usually a noob user) does not restore the previous tabs
then there is no way I can recover the long-term tabs unless they are in 'Recently Closed Tabs'.

This may also be true without #3 the browser crash - I can't easily test without closing all my tabs and being logged out of bugzilla due to clearing the history!

I propose that every time the browser is started and re-opens the previously opened tabs then those tabs should be re-entered in to History.

This closes the chance of losing tabs/urls/history.

Reproducible: Always

Steps to Reproduce:
1. Open a tab
2. clear the history
3. have a browser crash that (for whatever reason, usually a noob user) does not restore the previous tabs
Actual Results:  
The opened tab is not in History

Expected Results:  
The tab should be in History

Comment 1

[james.carlyleclarke]

Missed out the following, which makes the above make more sense:

Step 2a. Close the browser. Reopen the browser. Repeat as desired.

This makes more sense, as I am proposing that every time the browser starts and re-opens old tabs they should be stored in history, and my 'Steps to reproduce' did not include the browser starting.

Comment 2

[Marco Bonardo [:mak]]

From a history point of view, restoring any history after a clear history would be a privacy hit, and we'll never do that.

What's left seem to be the common session restore behavior, if you have a crash that prevents session restore from working that's just a session restore bug.

This bug as it is is either incomplete(for session restore) or wontfix (for history). This I'm moving it to session restore to let them figure out if this is a dupe of an existing request.

Comment 3

[james.carlyleclarke]

Sorry, maybe the way I explained it wasn't clear.

The pages are still open in the browser after the clear history, and indeed after restarting Firefox one or more times, for example 20+. Months may have passed with the tabs opening every time Firefox opens, and STILL the pages are not in the history.

The pages should be removed by Clear History, but afterward, when the browser starts with them already open, they should be added back in.

Hope that's clearer.

Comment 4

[B.J. Herbison]

I can reproduce the situation, and I agree that it is a session restore bug. A newly restored tab would reasonably be perceived by the user as a page visit and part of browsing history, but session restore doesn't place the URL in the history.

Comment 6

[Elbart]

This behavior is also skewing the frecency of these sites.
I.e. I have a session which I'm restoring on a daily basis, and a couple of these URLs are still clocked in as being last visited in 2013. Just because I haven't accessed these pages "normally" or reloaded them in the tab.
These URLs also don't pop up in the top-entries of the locationbar-results when typing the first letters of their addresses, although they're easily the most visited pages in my history.

In bug 429602 it was said that "not updating history makes sense", because "you don't really visit those pages anew, but rather just stay on them in the same session (which is continued thanks to our Session Restore feature)".

I disagree, because the pages, whenever they are visited after restoring a session, either after restart or with the use of an addon, are visited NOW, loaded NOW with contents which are accessible NOW, and not from the day they were visited before they were saved in the session.

Comment 7

[Kestrel]

Attachment: bug613126.patch - new loadtype LOAD_HISTORY_UPDATE

This is definitely an issue, affecting frecency score, history sorting and history clearing. 

Restoring tabs from the session store is done using nsSHistory::ReloadCurrentEntry which uses the loadtype nsIDocShellLoadInfo::loadHistory (LOAD_HISTORY) which is the same as navigating through history, it does not update global history. 

The code that decides whether to update global history is in nsDocShell::OnNewURI and can be changed easily enough, the only issue is a loadtype flag is needed to tell it what to do. 

The loadtype LOAD_HISTORY currently implicitly bypasses updating history despite not having nsIWebNavigation::LOAD_FLAGS_BYPASS_HISTORY. By adding this flag to LOAD_HISTORY it allows for the creation of a new loadtype, LOAD_HISTORY_UPDATE, that has no flags and can be used to update the history. LOAD_FLAGS_BYPASS_HISTORY has a very straightforward purpose with no other appearances in the code so this change should not be disruptive.

Due to several conditional checks on LOAD_HISTORY, instead of having to add LOAD_HISTORY_UPDATE everywhere, these checks are changed to use the more general LOAD_CMD_HISTORY.

This patch passes the tests for docshell and sessionstore.

Comment 8

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 8627635 [details] [diff] [review]
bug613126.patch - new loadtype LOAD_HISTORY_UPDATE

I don't understand why we'd need this. Isn't the issue, if there is issue, that we don't store the right data in session restore?

Comment 13

[Mike Conley (:mconley) (:⚙️)]

Just looked at this. With our current behaviour, after all history is cleared, if there are any tabs still open, we will persist those to the session store. So long as the crash doesn't occur before content has a chance to tell the parent about the tabs (and before those tabs can be written to disk), we can recover.

I think this is WORKSFORME. Please re-open if I've misunderstood here.

Comment 14

[B.J. Herbison]

Attachment: I started Nightly and tabs from the previous session were opened. But History is empty.

Comment 15

[B.J. Herbison]

If I start Firefox (Nightly in my case) and tabs are opened, the pages in those tabs should be in History. This isn't the case as you can see from the screen shot I just attached.

I opened and closed Nightly three times and the behavior was consistent: Pages were loaded but not placed in History.

Comment 16

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 4 duplicates and 19 votes.
:ke5trel, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 17

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.