329949 - browser.tabs.loadBookmarksInBackground is ignored in places views (histrory sidebar, bookmarks toolbar etc.)

Status: RESOLVED FIXED

(Firefox :: Bookmarks & History, defect, P2)

Description

[Brian Polidoro]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060309 Firefox/1.6a1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060309 Firefox/1.6a1

In current builds (trunk or 1.8 branch) bookmarks that are middle clicked are always opened in a background tab no matter what the value of browser.tabs.loadBookmarksInBackground is set to.

Reproducible: Always

Steps to Reproduce:
1. Middle click on a bookmark 
2.
3.

Actual Results:  
Bookmark is always opened in a background tab.

Expected Results:  
Bookmark should follow browser.tabs.LoadBookmarksInBackground

works  2006-03-07-04-mozilla1.8
broken 2006-03-08-12-mozilla1.8


Bookmarks will open in foreground tabs if browser.tabs.loadInBackground is set to false.  But then middle clicking on web page links will also open new foreground tabs which is not desired (at least by me).

Comment 1

[Brian Polidoro]

browser.tabs.loadBookmarksInBackground does still work for the home button.

Comment 2

[Brian Polidoro]

browser.tabs.loadBookmarksInBackground also still works for the back & forward buttons.

Comment 3

[Annie Sullivan]

This was fixed by the patch for bug 330130.

Comment 4

[Annie Sullivan]

Whoops, marked the wrong bug.  Sorry.

Comment 5

[mmortal03]

This regression also seems to have broken the way the tab generated by the Search bar and the "Search Web For" context menu option open.  Now all tabs generated from those open in the foreground, regardless of any configuration settings.  They used to obey one of the other about:config options.  Should I make a new bug, or should this bug cover it?

Btw, I see this in both the trunk and the branch from 20060321.

Comment 6

[Mike Connor [:mconnor]]

That's almost certainly due to the search rewrite and nothing due to places, please file a bug against [e-mail] and cc me.

Comment 7

[Ria Klaassen (not reading all bugmail)]

With a profile's default settings: rightclick on a places' history link and choose Open in New Tab and the link opens unexpectedly in the background. Double middle-clicking opens that link in the foreground however.

Comment 8

[Ria Klaassen (not reading all bugmail)]

I've scrutinized this in depth ;) but I think it is a places bug.
In a places build, links open in the background, and in a recent build without places, in the foreground. Both tested with the same profile.
I get this as regression range:
http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=2006-03-04+13%3A00&maxdate=2006-03-04+22%3A00

Comment 9

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

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

Comment 10

[chris hofmann]

If we flip places on for the upcoming trunk alpha I'm guessing a fix for this would be good.

Comment 11

[Brian Polidoro]

Changing the blocking flags and milestone since Places won't be in alpha 1.  

Comment 12

[Asaf Romano (gone)]

This also affects the history sidebar context menu.

Comment 13

[Asaf Romano (gone)]

Attachment: patch

Comment 14

[Asaf Romano (gone)]

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

Comment 15

[(not reading, please use [e-mail] instead)]

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

r=sspitzer, thanks for fixing this for the history sidebar (and the rest of places)

Comment 16

[Asaf Romano (gone)]

mozilla/browser/components/places/content/controller.js 1.105
mozilla/browser/components/places/content/places.js 1.69
mozilla/browser/components/places/content/places.xul 1.51
mozilla/browser/components/places/content/placesPopup.xul 1.4
mozilla/browser/base/content/browser-places.js 1.15

Comment 17

[tabmix.onemen]

you miss a spot in PlacesController.prototype.openLinksInTabs

for (var i = 0; i < nodes.length; ++i) {
    getTopWin().openNewTabWith(urlsToOpen[i], null, null);
}

and nodes.length is not always the same as urlsToOpen.length

do you think gBrowser.loadTabs() can be in use from here ?

Comment 18

[Asaf Romano (gone)]

(In reply to comment #17)
> you miss a spot in PlacesController.prototype.openLinksInTabs
> 
> for (var i = 0; i < nodes.length; ++i) {
>     getTopWin().openNewTabWith(urlsToOpen[i], null, null);
> }
> 

Intended, focus changes are not desired for this case.

> and nodes.length is not always the same as urlsToOpen.length
> 

Good catch, thanks! (fix checked in, see bug 365100).

> do you think gBrowser.loadTabs() can be in use from here ?

probably, please file a bug. 

Comment 19

[tabmix.onemen]

there is bug 331908 - Improve openLinksInTabs

Comment 20

[Gervase Markham [:gerv]]

Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h".

In Thunderbird 3.0b, you do that as follows:
Tools | Message Filters
Make sure the correct account is selected. Click "New"
Conditions: Body   contains   places-to-b-and-h
Change the action to "Delete Message".
Select "Manually Run" from the dropdown at the top.
Click OK.

Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter.

Gerv