User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008031304 Minefield/3.0b5pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008031304 Minefield/3.0b5pre There are certain cases where clicking on a link in the library / places organizer / bookmarks manager should not have the browser steal focus. Options should be created to deal with these certain cases. One case is when middle clicking on a bookmark in the library. I would like the library to stay on top AND never lose focus as the link is opened in a new tab in the browser window. It could be argued that this should actually be the default behavior for middle clicks in the Library, but I will leave this open for discussion, and if we come to the conclusion that it is not, it would be useful for the minority to at least have an option to choose this behavior. I have initially marked this bug as an enhancement, because it depends on interpretation. Reproducible: Always Steps to Reproduce: 1. Middle click on a bookmark in the Library Actual Results: Browser window steals focus from Library as the link is opened. Expected Results: Browser window remains in background as the link is opened.

I think the Library window should in any case stay on top if you have set browser.tabs.loadBookmarksInBackground to true. Which is a regression from Firefox 2 where the Bookmarks Manager stays on top if the bookmark is loaded in the background. So this bug is partially an enhancement request and partially a regression. Which one do you prefer?

Because I think these are two separate bugs.

(In reply to comment #1) > I think the Library window should in any case stay on top if you have set > browser.tabs.loadBookmarksInBackground to true. > Which is a regression from Firefox 2 where the Bookmarks Manager stays on top > if the bookmark is loaded in the background. So this bug is partially an > enhancement request and partially a regression. Which one do you prefer? > Yeah, I thought of browser.tabs.loadBookmarksInBackground too, but I didn't want to attach the bug to any particular prefs option from the beginning, as I wanted to leave it up to discussion such that we could fully think this one out. Also, I didn't know that in Firefox 2 the Library was indeed staying on top on middle-clicks if that option was set. If that is true, we can open a separate bug report for that, and leave this one open for further, more in-depth enhancement discussion about the general ideas surrounding this. Just as an aside, I have learned from past bug reporting that the leadership around here has the tendency to be WONTFIX-happy if you make your enhancement requests too prefs-option-specific, even if the general concept behind it is good, so figured I would keep the description more general and all encompassing, so that I wouldn't have to create multiple bug reports reiterating a more and more general idea. But getting back to the point, first, I have to make the point that browser.tabs.loadBookmarksInBackground set to true currently just works within the context of tab selection behavior, and the option does operate properly within that current context when middle-clicking on links in the Library, both when it is set to false and to true. When it is true, the tab doesn't steal the focus of the current tab, and if false, it correctly selects the new tab. Now, yes, in the more general usage pattern context, the issue of the Library having focus, however separate from dealing with just tabs getting selected or not on middle click, may in fact be in the same vein as this, and may in fact parallel the two usage behaviors of people that would set that option true and those that would set it to false. I guess the issues to look at would be whether there are people who set browser.tabs.loadBookmarksInBackground to true, but still want their Library to lose focus, and/or whether there are people who set browser.tabs.loadBookmarksInBackground to false, but still want their Library to retain focus. I can't think of a usage pattern for the former case, but for the later case, I can. Having a separate boolean option for this in existence might lend itself to further UI implementation of a toggleable option to "have Library retain focus for middle clicks" which would be independent of the Bookmarks tab selection behavior option. I could also see people who might want to, in certain transient situations, toggle an similar option to "have the Library retain focus for left clicks", but that is a separate issue, but we could discuss it here further, as well.

The problem is that regressions are nearly always blocking a release, and enhancements only rarely.

Like I said, I have no problem with creating a separate bug report specifically relating to the specific regression behavior that you are speaking of, if, in fact, it is a regression. I hadn't realized that it was. I will have to pull out my laptop, which has Firefox 2 installed and test it.

not going to block on implementing new behaviour like this.

(In reply to comment #5) > Like I said, I have no problem with creating a separate bug report specifically > relating to the specific regression behavior that you are speaking of, if, in > fact, it is a regression. I hadn't realized that it was. I will have to pull > out my laptop, which has Firefox 2 installed and test it. > Yeah, there is a regression when browser.tabs.loadBookmarksInBackground is set to true, based on my testing of Firefox 2. I have created a bug report for that specific regression: Bug 423789

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

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.