shift->middle clicking on a folder of bookmarks should not replace the currently existing tab (unless it is blank), if browser.tabs.loadFolderAndReplace is set to false




12 years ago
10 years ago


(Reporter: mmortal03, Unassigned)


Firefox Tracking Flags

(Not tracked)




12 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007101905 Firefox/3.0a6pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007101905 Firefox/3.0a6pre

I guess Mike wanted me to create a whole new bug, because he didn't open it back up when I changed Bug 399113's description.

Basically, if browser.tabs.loadFolderAndReplace is set to false, 
shift->middle clicking on a folder of bookmarks should not replace the currently existing tab unless it is blank.

Reproducible: Always

Steps to Reproduce:
1. Set broswer.tabs.loadFolderAndReplace to false
2. Create a folder with multiple bookmarks.
3. Go to your homepage
4. Hold Shift and middle click on the folder of bookmarks you created.
Actual Results:  
The bookmarks open in new tabs, but the first bookmark replaces your homepage tab.

Expected Results:  
The bookmarks open in new tabs but don't replace any open tabs.
I'm seeing the following unexpected behaviour:

- I set browser.tabs.loadFolderAndReplace;false
- load 3 pages in tabs
- focus the first tab
- shift+middleclick on a bookmarks folder
- result: the first tab is replaced by the first bookmark of the folder (with a green back icon), then followed by the next bookmarks of the folder (without enabled back button), and entirely at the end you see the other two tabs. So the folder is loaded between the three tabs; which is a bit surprising.

Ever confirmed: true
This bug was caused by bug 175124 on 2 Sept 2007.
urrgh. This bug was the first one to get my attention when I first tried out Fx 3 Beta 1.

Just tested that Fx 3 Beta 1's behaviour differs from Fx 2. Now lots of my existing tabs get "over-written" even though I set loadFolderAndReplace to false.

Is this intended behaviour? Otherwise it should get nominated IMHO.

Comment 5

12 years ago
in Firefox3 Beta1, eventhough browser.tabs.loadFolderAndReplace is set to true, it very very very rarely overwrites the currently open tabs when "open all in tabs" is selected for a bookmark folder.
i've seen the behaiour of "open all in tabs" change from time to time

Comment 6

12 years ago
(In reply to comment #5)
that pref should be ignored by design.  see current intended behavior at bug 175124 comment 29; Bug 395024 is removing the prefs entirely (they already serve no purpose though)

Comment 7

11 years ago
For clarification, holding shift should, by design, open all the tabs in the background instead of the foreground, and should not affect whether tabs are replaced or not.  This bug deals with the problem that a tab is getting replaced when holding shift.  

The bug regarding the Firefox 3 removal of the option to open groups of bookmarks into the background without holding shift is a different issue, and has been unfortunately been denied as WONTFIX.


11 years ago
Blocks: 452183

Comment 8

10 years ago
This bug is obsolete. I don't think shift+middle-click-on-a-folder should even do what this bug is describing anymore.  The keystroke needs to be cleaned up and made to follow the same functionality as right-clicking on a folder, holding down shift, and then left-clicking on "Open All in Tabs", which opens all tabs in a new window. 

Right now, carrying out a shift+middle-click-on-a-folder initiates some kind of buggy behavior of "replace the first tab, append the selected folder's contained links next to the first tab, and leave the other, prior existing tabs appended to the end of those".

I have created a whole new bug report for this,  Bug 472966.

For those of you who wanted the browser.tabs.loadFolderAndReplace setting to go back to being followed, it is a ctrl+middle-click, not a shift+middle-click, that we now need to have follow it, and that needs another new separate bug report created. We probably aren't even going to get it, anyway, but we can at least try, so please create a new bug report for that if you still want it.
Last Resolved: 10 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.