236394 - Links opened in new tabs are not added to History

Status: RESOLVED FIXED

(Firefox :: Bookmarks & History, defect)

Description

[u60234]

A link opened in a new tab or window does not get added to History. That link is
then also blocked from being added when opened in a current tab.

Steps to reproduce:
1. Open the History sidebar and make sure you can see any new entries that are
added, i.e. open the "Today" group if you sort by date.
2. Open a page that have multiple links on it, for example a Bugzilla search
result page, or this page.
3. Open one of the links not previously visited in a new tab or window.

Result:
The new page is not added to History, and is also stopped from being added at a
later date, new tab or not.

This is a regression between the 2004-02-16 and 2004-02-17 builds.

Comment 1

[Jesse Ruderman]

Blake fixed bug 234136 (links opened in new tabs aren't marked as visited) on
Feb 16, so he might have caused this regression.

Comment 2

[Brian Ryner (not reading)]

This regressed between 2004-02-16-08 and 2004-02-17-08, so the window fits with
that checkin.

Comment 3

[Brian Ryner (not reading)]

I think the problem is that the entry is getting set to hidden, because it hits
this logic in nsGlobalHistory::AddPageToDatabase:

    if (isJavascript || aRedirect || !aTopLevel) {
      // if this is a JS url, or a redirected URI or in a frame, hide it in
      // global history so that it doesn't show up in the autocomplete
      // dropdown. AddExistingPageToDatabase has logic to override this
      // behavior for URIs which were typed. See bug 197127 and bug 161531
      // for details.
      rv = SetRowValue(row, kToken_HiddenColumn, 1);

We pass aTopLevel == false for adding URIs opened in new tabs.  Should we be
passing true?

Comment 4

[Benjamin Smedberg]

Yes, we should be setting aToplevel for new tabs (aToplevel == false is for
sub-frames, which doesn't apply here).  Does this bug exist in seamonkey also?

Comment 5

[Brian Ryner (not reading)]

I couldn't find anything like this in SeaMonkey.

Comment 6

[ratman]

using build: 
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040303
Firefox/0.8.0+ (mmoy)

personally, i don't think bug 234136 is fixed, though i haven't had a
middle-click button until recently.  smells dupe-ish.

Comment 7

[Brian Ryner (not reading)]

Attachment: patch

Comment 8

[Ben Goodger (use ben at mozilla dot org for email)]

Comment on attachment 144532 [details] [diff] [review]
patch

r=[e-mail]

Comment 9

[Brian Ryner (not reading)]

checked in.