Closed Bug 395024 Opened 17 years ago Closed 15 years ago

browser.tabs.loadFolderAndReplace is obsolete, remove it from firefox.js

Categories

(Firefox :: Bookmarks & History, defect)

Product:
Firefox
Component:
Bookmarks & History
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Firefox 3.7a1

People

(Reporter: moco, Assigned: mkohler)

References

Details

Attachments

(1 file)

deletes browser.tabs.loadFolderAndReplace from firefox.js
(deleted), patch
mak
: review+
Details | Diff | Splinter Review 
support browser.tabs.loadFolderAndReplace or browser.tabs.loadFolderAndReplace obsolete, remove it from firefox.js

bug #175124 has removed support for browser.tabs.loadFolderAndReplace, but we still have:

/browser/app/profile/firefox.js, line 270 -- pref("browser.tabs.loadFolderAndReplace", true);

from bug #175124 comment #29:

click on Open in Tabs replaces the currently selected tab with the tabset
Ctrl/Cmd+click on Open in Tabs appends the tabs and selects the first tab of
the set (foreground load)
Ctrl/Cmd+Shift+click on Open in Tabs appends the tabs and leaves selection
alone (background load)

although it appears as by design and after much discussion, I'm a little concerned about "open in tabs" (by default) replacing the selected tab.
  
are users like me, and they use tabs as "a todo list"?  

I see that I can get back to my replaced tab (with the back button), but it still has a data-loss like feel.  

(the Ctrl/Cmd+click listed above sounds like what I'd want.)

what about restoring support for browser.tabs.loadFolderAndReplace, so that click on Open in Tabs will not replace?

thanks to rob strong for pointing this out.
I'd like to see returned support for loadFolderAndReplace, at least as an advanced / config option for those who know how. I suspect it's a fairly common thing to not want your "open all in tabs" to replace your current tabs, and therefore it's a bit aggravating that you can't have it do that by default anymore. At least ctrl/cmd-click works, though I never thought to try that before now because I thought the pref was simply broken.
Yeah, tabs should NEVER replace other tabs, unless those other tabs are blank.  This option can be removed as long as things like Bug 400491 no longer occur.
(In reply to comment #0)

> from bug #175124 comment #29:
> 
> click on Open in Tabs replaces the currently selected tab with the tabset
> Ctrl/Cmd+click on Open in Tabs appends the tabs and selects the first tab of
> the set (foreground load)
> Ctrl/Cmd+Shift+click on Open in Tabs appends the tabs and leaves selection
> alone (background load)
> 
> although it appears as by design and after much discussion, I'm a little
> concerned about "open in tabs" (by default) replacing the selected tab.
> 
> are users like me, and they use tabs as "a todo list"?  

The Mac builds do not seem to allow the use of Ctrl/Cmd while clicking on a menu (see Bug 313718), and therefore I can't get back my preferred behavior of "never replace a tab".  
I disagree. I am quite fond of the auto replace tabs feature. If an option is added to determine whether you want all tabs cleared and replaced or added to existing tabs, it should be and to easy find option in the tabs preferences. I use this feature to surf web sites that I routinely visit and I don't need an excessive number of tabs opened at one time. In Firefox 2.0 all tabs were replaced by default and this was the behavior I have come to expect from Firefox. Now with Firefox 3 Beta 2 this is no longer the case. 
(In reply to comment #0)

[munch]

> from bug #175124 comment #29:
> 
> click on Open in Tabs replaces the currently selected tab with the tabset
> Ctrl/Cmd+click on Open in Tabs appends the tabs and selects the first tab of
> the set (foreground load)
> Ctrl/Cmd+Shift+click on Open in Tabs appends the tabs and leaves selection
> alone (background load)

Actually, Ctrl+Shift+click on Open All in Tabs does NOT append the tabs and does not leave the selection alone in Firefox 3 Beta 2.  At least it doesn't for me.

Ctrl+click does function as advertised but Ctrl+Shift+click replaces the active tab with the first tab in the group.  That is, it does the same as simply clicking "Open All in Tabs".

I'm the one who reported the supposed dupe Bug 409122.  I don't think this issue is a duplicate because there are several different issues going on.  The one that I'm concerned about is that if you had brower.tabs.loadFolderAndReplace set to false in Firefox 2, you got one behaviour, and if you have it set to false in Firefox 3 Beta 2 (and Beta 1), you get another.  That's not a good thing.  On top of that, the given workaround doesn't work.
I added a bug that specifically addresses the new behaviour, it is bug 426127.
This changed behavior of "open all in tabs" in 3.0beta is indeed very annoying.

open-all-in-tabs with loadFolderAndReplace=false worked just the way it should in FF2, i.e. appending all newly opened tabs and without replacing or closing other tabs nor changing the active tab.

I would now need to hit control+shift every time I select "open all in tabs", which is a royal pain and was not needed before (and which doesn't even work in 3.0b4, as mentioned in comment #8, but that's another issue).

If some users prefer a different behavior when opening a group of tabs that's fine, but be aware that other users may actually like the FF2 behavior and want to continue doing things that way.

So please put back support for brower.tabs.loadFolderAndReplace=false, and add a "smart replace" option for those who prefer the new behavior.

I open groups of tabs many times per day, and this issue is sufficiently annoying to consider going back to FF2 if it doesn't get resolved before 3.0 is released...
I strongly agree that loadFolderAndReplace should be permanently supported.  I am using FireFox 3.0b5 and it is still an issue.  

I have five sets of tabs on my bookmark bar that I load regularly throughout the day, and when I am done with a set, I simply click on the next to replace the set of tabs from set #1 to set #2, etc.  

Appending simply uses a ton of memory by opening a bunch of unnecesary and unasked for tabs.  I don't even mind if this is the default behavior (though I wish it weren't, its not a big deal), but I want the option, even if I have to go to about:config.
I have the same situation as mneumark.

> I have five sets of tabs on my bookmark bar that I load regularly throughout
> the day, and when I am done with a set, I simply click on the next to replace
> the set of tabs from set #1 to set #2, etc.  

I think I understand the reason for changing the default to a "safer" behaviour, but I do not understand at all taking away the users' ability to configure this one way or the other.   Please reconsider bringing back the ability to configure this, even if it must be done through about:config.
For power users, they probably would want tabs to be replaced on loading bookmarks in a folder.  It is simply faster to load a new set of tabs in the new window, overriding the old ones, rather than having to close the window or closing all the old tabs first.  The new way of doing things in FF3b3 just wastes my time.

I am a POWER user and I open about 400 tabs/day.  I find Firefox 2 quite slow because it is mainly single-threaded.  Even though Firefox 3 is still single-threaded, it has improved performance by a lot.  But without this old FF2 behavior, I won't be using FF3 because it will just slow me down overall.
Me too, I just installed RC1 and the option to change it still does not work. Why did you guys remove the option to alter this behavior, also why not add a option to change it in the options menu?

I am now forced to stay using FF2, simply because I find it annoying to close any remaining tabs in order to open a bookmark folder or closing firefox, then to open it, close my start page tab and finally open the bookmark folder.

It is indeed a waste of time this way.

*uninstalling rc1*

Some people seem to like the FF2 loadFolderAndReplace=true behavior, in particular when a set of links is loaded frequently. Why not support this option in FF3 with default=false?

If this for some reason is not an option, has anyone figured out a way
to change the source code to reinstate replacing old tabs by new ones?
I would be happy to recompile newer FFs myself just to get the old behavior 
back.
I can only concur with the previous comments about the usefulness of the browser.tabs.loadFolderAndReplace preference when set to true. This has made firefox tabbed browsing quite efficient up until now, especially when working with lots of well organized bookmark folders. Hasn't this been the default behavior since phoenix back then? The result of the action is indeed "sharp" but is part of what made firefox working with so fast and clear everyday. 

On a side note this also makes 3.0 betas and RC1 testing more difficult and less appealing as it completely changes the tabbed browsing experience for people who _strongly_ relied on it, as if we were testing a totally different product.

I’m fine with redefining firefox standards to softer behaviors and being more forgiving, but please support this particular functionality with just a simple check box in the options panel under the "Tabs" tab like in early builds (there is still a lot of empty space there as you can see) so that it has some kind of visibility for new firefox users who could obviously benefit from it, or at least via the about:config.

There is a big discussion and argument going on resulting in making
browser.tabs.loadFolderAndReplace obsoleted !!!

I do not want to go to the core of the argument "should open in tabs" overwrite
existing open tabs or append. Both sides are valid and legitimate uses.

Make one option a default - that would make supporters of one argument happy.
Keep browser.tabs.loadFolderAndReplace working so supporters of another
argument can be happy too.

This may be silly but a lot of people are very unhappy with your arbitrary
decision to go one way and lock out everybody else who do not agree with your
choice. I am one of them and this alone may make me to stop using FF.

I cannot believe what I am writing here but in 2008 a community driven project
behaves like Stalin in 1938. Get a grip, please.

Would the old code for this feature even work anymore?
TabMixPlus (TMP) extension now supports this, and the current build at the developer's website (http://tmp.garyr.net/forum/viewtopic.php?t=8841)  is compatible with FF 3.0rc1 .

By default, opening a group of tabs from the bookmarks will replace all tabs in the current window (same as loadFolderAndReplace=true).   TMP has a config option to cause it to open the group in new tabs if that's what you want.
Flags: blocking-firefox3?
I agree. Everyday I visit lots of sites, and I open them in blocks based on folders of bookmarks. I find it correct and comfortable for the "Open all in tabs" command to overwrite existing tabs, so that when I change the bookmark block, the tabs I already opened disappear. This option should at least be available through the about:config settings. I don't need to install a whole new extension just to toggle a setting.
Not a blocker.
Flags: blocking-firefox3? → blocking-firefox3-
I would like to add a comment that I have checked, and this is still a MAJOR SERIOUS issue as of Firefox 3.0 RC2.
(In reply to comment #24)
> I would like to add a comment that I have checked, and this is still a MAJOR
> SERIOUS issue as of Firefox 3.0 RC2.

I agree.  If I select Open In Tabs, I want that group to replace whatever other tabs are displayed.  I don't understand why this can't be a config option (or at least a Ctrl/Alt key type option).  I'm sure ton's of other people are gonna be unhappy when they upgrade to FF3.
>I'm sure ton's of other people are gonna
>be unhappy when they upgrade to FF3.

But how does that group compare in size to the group of people who are unhappy because clicking on a folder effectively obliterated their current session?

Perhaps we should consider adding "Open all in a New Window." That would make the folder contextual menu more consistent with the individual bookmark contextual menus, and would give users the the types of topic specific tab sets they are looking for.  I filed bug 437526 to track that possible change.
(In reply to comment #26)
> But how does that group compare in size to the group of people who are unhappy
> because clicking on a folder effectively obliterated their current session?

Who exactly?  The people I've heard complaining about FF2's current behavior have idealogical reasons (versus real use cases).  The fact is, people store more than 3 bookmarks in a folder.  It quickly becomes information overload if FF doesn't replace the current bookmarks.  Furthermore, in FF2, people can always change the default loading behavior with loadFolderAndReplace.  In FF3, the old behavior has been removed totally.

> 
> Perhaps we should consider adding "Open all in a New Window." That would make
> the folder contextual menu more consistent with the individual bookmark
> contextual menus, and would give users the the types of topic specific tab sets
> they are looking for.  I filed bug 437526 to track that possible change.

That wouldn't fix the original issue, which is that loadFolderAndReplace is stuck on false in FF3.  People subscribed to this thread do not want to waste time closing the old set of tabs/windows.  "Open all in a New Window" will not be an improvement at all over FF3 RC2's current behavior.
Having options is great.

Sometimes I'm looking for say, running shoes, and I open several types of running shoes reviews in pages. Then I bookmark them all. Next day I keep looking for more running shoes, because my friend stephend, said such and such were better. So I look for those, and I remember that I have already bookmarked a few in a folder. I'd like to compare them all in the same window, so if I select my "running shoes" folder and try to open all in tabs. I want the tabs I already have open plus the ones from the folder.

However if I have already compared all my running shoes and I now want to check fancy, dapper shoes from another folder "fancy shoes", I would like for my running shoes tabs to disappear from that current window.
(In reply to comment #28)
> Having options is great.

Totally agree.  The loadFolderAndReplace option should be configurable, which it is not in FF3 RC2.  As a compromise, "Open all in Tabs (Append)" and "Open all in Tabs (Replace)" could both be selectable actions, or one action is the default and the other action is selected by Ctrl + Left_Click.

> 
> Sometimes I'm looking for say, running shoes, and I open several types of
> running shoes reviews in pages. Then I bookmark them all. Next day I keep
> looking for more running shoes, because my friend stephend, said such and such
> were better. So I look for those, and I remember that I have already bookmarked
> a few in a folder. I'd like to compare them all in the same window, so if I
> select my "running shoes" folder and try to open all in tabs. I want the tabs I
> already have open plus the ones from the folder.

This is a resume operation.  How often will you need to look for "running shoes" ?  Probably once a year or two.  I don't believe many people will bookmark pages where they are likely to only visit at most twice, and having later to delete them a couple of days later.
The point of "Open all in Tabs" is simply to save time.  I think the discussion should revolve around this original intent, and changes to it should put emphasis on frequent use cases. 
Another voice in favour of the old behaviour here: I have a set of four tabs, and I used to regularly use "Open in tabs" as a quick shorthand for "refresh the contents of all four tabs, additionally replacing everything that I've opened in a tab since". It was a quick way to get FF back to a known state.

Definitely in favour of the old behaviour, however I understand that others might prefer the new behaviour so it sounds like fixing this option is the way forward.
I had not noticed this in the beta, because I didn't have any tab groups on my test machines. It seems absurd to change the default action and at the same time remove the option! This change results in at least three extra clicks for me to close existing tabs before opening a tab group. I have 4 tab groups of about 15 tabs each that I regularly read sequentially. I would put them in one group, but loading 60 tabs at once has not been a good thing. So now I am forced to live with the new behavior. 

But even this new behavior is inconsistent.

1) With one page displayed and you open the tab group: The existing page is replaced with the first tab of the tab group, the rest are appended.

2) With multiple tabs open and you open the tab group: The new tabs are not appended but INSERTED at the currently selected tab.

So I plea to restore the previous behavior, or at least restore the preference so I can override it. I see bug 437526, but I don't want a new window. I want the currently displayed tabs replaced with the selected tab group. If I click on a regular bookmark I don't get a new tab unless I hold Ctrl. It replaces the currently displayed tab. The new behavior is both counter-intuitive and inconsistent with the single-page bookmark action.
I want the old behavior as well.  I can see the usefulness of NOT replacing tabs, but that's now how I use my browser.  I always want to use the behavior to replace the existing tabs with my new folder of bookmarks.

This is a showstopper for me to use FF3.  I may even see what I can do with IE for my regular browsing.
Can we stop with all the advocacy please. Bugzilla is not the appropriate forum for "i want this fixed" comments. If you want to register your support for a bug, vote for it. But please read https://bugzilla.mozilla.org/page.cgi?id=etiquette.html and stop with the comments that contribute nothing to any technical fix that may or may not be forthcoming.
I may have found a partial workaround for the Firefox 3 bug where it fails to respond to browser.tabs.loadFolderAndReplace being set to false.

Case 1) open a few tabs (in Firefox 3), give focus to the first (usually leftmost) tab. 
Open a group of tabs when browser.tabs.loadFolderAndReplace being set to false. Old tabs are replaced with the new tabs. This shows the bug at its worst.

Case 2) open a few tabs (in Firefox 3), then open a new tab (an "empty" tab) and give this new tab (usually the rightmost tab) focus; now when you open a group of tabs, it seems to start "there" with that empty tab for the first new tab in that group, and open the additional new tabs to the "right" of that one (leaving the first few tabs in their "original" states). This allows opening of a new group of tabs without "wiping out" your original tabs. This was the desired behavior of browser.tabs.loadFolderAndReplace being set to false, but it only seems to work when starting the load of a tab group from the "rightmost" (newest) tab.

Steve, with respect to comment 34 and advocacy, this bug has an ambiguous title. It says support -or- remove, either would be regarded as a 'fix'.

The advocacy from myself is just opinion that removal would be bad, and that supporting it is the preferred way to go. I think the title of the issue should be edited to remove the "or obsolete" section and it would add clarity to the purpose of this issue.
For anyone looking for a way to use the old behavior, I have found that both Ctrl-Shift-LeftClick and Shift-MiddleClick can be used on the desired folder to get the desired result.

I'm glad to see there is a solution, although I'd still prefer having the old behavior as an available option in the about:config setup.
(In reply to comment #37)
> For anyone looking for a way to use the old behavior, I have found that both
> Ctrl-Shift-LeftClick and Shift-MiddleClick can be used on the desired folder to
> get the desired result.

Does not work here, tha tabs are appended as usual.

I also just downloaded Firefox 3 and I am gretly missing the feature of opening
grouped tabs, that replaces the old ones.

I think this option is vital for many users, and hops that this feature will
bea available again. If not, i'm personally is going back to Firefox 2.

Another thing - Why remove it in the first place - the loadfolderandreplace has
always been an OPTION! Then people can decide on there own, what they want.

You broke my firefox:-(

/Morten
After more testing, i have noticed some additional aspects of the way Firefox 3 (FF-3-Final on Win-XP-SP3) responds to browser.tabs.loadFolderAndReplace when set to false.

I previously thought it was overwriting old tabs instead of adding new tabs at the end. And i had also found that if i gave focus to a "new" (blank) tab at the rightmost end of the tabs, that launching a new group-of-tabs would then seem to add new tabs off to the right of the previous tabs (leaving the original tabs "unchanged"). 

Well... now i am discovering that that the behavior is actually more of a "hybrid" between opening a group of tabs in "new" tabs" and opening them in "already-in-use" tabs.

If i have, let's say, 5 tabs open and i give focus to the "third" one, trying to open a new group of tabs opens the "FIRST" new tab by OVERWRITING the current tab with focus; HOWEVER, the remaining tabs in the group to be opened are "inserted" between that tab which had focus and the tab to its right. So "most" of the new tabs are getting their own new tab, but the "first" tab in the group to be opened overwrites whatever tab had focus (the currently selected tab).

I do say this is a "bug", acting differently than advertised. It is not "overwriting" nor is it "appending"; it is doing a little-bit-of-each. 

Question, is bug: 
https://bugzilla.mozilla.org/show_bug.cgi?id=173406 
("Open in tabs" should have a prefable option: replace vs. append) 
basically an older "duplicate" of this same issue? 

It sure seems like a duplicate... 
(In reply to comment #40)
> Well... now i am discovering that that the behavior is actually more of a
> "hybrid" between opening a group of tabs in "new" tabs" and opening them in
> "already-in-use" tabs.
> 
> If i have, let's say, 5 tabs open and i give focus to the "third" one, trying
> to open a new group of tabs opens the "FIRST" new tab by OVERWRITING the
> current tab with focus; HOWEVER, the remaining tabs in the group to be opened
> are "inserted" between that tab which had focus and the tab to its right. So
> "most" of the new tabs are getting their own new tab, but the "first" tab in
> the group to be opened overwrites whatever tab had focus (the currently
> selected tab).
> 
> I do say this is a "bug", acting differently than advertised. It is not
> "overwriting" nor is it "appending"; it is doing a little-bit-of-each. 

Yes, this is a deliberate change, from what I can tell.  Basically, the idea is when you load a single bookmark, it overwrites whatever tab had focus.  So they changed the append behaviour to mimic this, with the current tab being overwritten by the first tab in the bookmark folder.

So there are two changes going on here: first, the one that many are vocally up in arms about, which is that they cannot get their bookmark folders to replace all the existing tabs in their window.  Second, the one where appending your bookmark folder tabs doesn't work like it used to because before if you had N bookmarks, you'd end up with N additional tabs after an append and now you end up with N-1 additional tabs.

In both cases, I think the developers should have left in options to provide the old behaviour.  Even though I can see how the second change (when appending a bookmark folder) is more consistent with other Firefox behaviour, it still represents a substantial change to how the program used to behave.
(In reply to comment #38)
> (In reply to comment #37)
> > For anyone looking for a way to use the old behavior, I have found that both
> > Ctrl-Shift-LeftClick and Shift-MiddleClick can be used on the desired folder to
> > get the desired result.
> 
> Does not work here, tha tabs are appended as usual.
> 

Check to make sure that the about:config option browser.tabs.loadFolderAndReplace is set to TRUE.  Hopefully this will allow you to use the shortcuts I gave.
(In reply to comment #38)
> (In reply to comment #37)
> > For anyone looking for a way to use the old behavior, I have found that both
> > Ctrl-Shift-LeftClick and Shift-MiddleClick can be used on the desired folder to
> > get the desired result.
> 
> Does not work here, tha tabs are appended as usual.
> 

Doesn't work either for me, when I use the middle click as it always append the tabs with browser.tabs.loadFolderAndReplace set to TRUE. But with SHIFT + right click and then select "Open all in tabs" does indeed work, whatever tab as currently the focus.

My bookmarks are organized by topic into folders (e.g. news, forums, webcomics, anime, ...). They are in seperate folders because I don't want them to mix with other bookmarks.

In Firefox 2, the 'Open All in Tabs' function was great, it would close all tabs and replace them with my bookmarks. So I'd have only tabs for the one topic I selected (all webcomics, or all forums). This way browsing was very efficient.

The new behaviour is useless. Instead of replacing all tabs, it replaces one tab (the current tab), and appends all others. So if I was reading webcomics, and then I open forums in all tabs, this kills one of my webcomics, leaves all others, and appends the forums. Then I will have tabs in this order: 5 webcomics, 7 forums, 9 more webcomics, 4 additional forum tabs I opened while reading threads, etc. It's chaotic.

Can someone who is actually happy with this append mode, describe his usage / workflow for me? Right now I can't see any use nor sense in this new behaviour.
"Works for me" ... "Doesn't work for me" ...
Please, when making such statements, tell us what OS you're on. On the Mac, FYI, the only working kind of clicking on a menu is just plain click. I bet many of the "Doesn't work for me" crowd are on Macs.
Uh, correction ... Shift+Click on "Open all in tabs" in a bookmark menu does work on the mac after all. I must have had finger trouble.
Interestingly, middle clicking on a folder in the left hand side of the library still replaces the current tabs.

Also, regarding issues with Shift+Middle click, people should see Bug 400491.
Regarding Comment #48:

For what it is worth: In FF 3.0.5 under OS X 10.5.6, middle clicking on a 'Open All in Tabs' pops up the tabs into a new browser window.  I have browser.tabs.loadFolderAndReplace set to TRUE.
Please, please, please restore/return/add the ability to configure firefox so that when I select/left-click 'Open All in Tabs' in a bookmarks folder, it will replace ALL tabs in the CURRENT window with tabs for the bookmarks folder!

Setting browser.tabs.loadFolderAndReplace set to TRUE does not help.  And Shift clicking creates a window.

For what it is worth, I am using FF 3.0.5 under OS X 10.5.6.
(In reply to comment #52)
> Please, please, please restore/return/add the ability to configure firefox so
> that when I select/left-click 'Open All in Tabs' in a bookmarks folder, it will
> replace ALL tabs in the CURRENT window with tabs for the bookmarks folder!
> 
> Setting browser.tabs.loadFolderAndReplace set to TRUE does not help.  And Shift
> clicking creates a window.
> 
> For what it is worth, I am using FF 3.0.5 under OS X 10.5.6.

Can you clarify?  Unless there is something deeper involved in what you are requesting, or something has changed in 3.0.5, what you are describing IS currently what Firefox is supposed to do by default, so there isn't even a need for this setting anymore, except in the opposite case described in Bug 400491 (which seems to now need revising, anyway).
(In reply to comment #53)
> (In reply to comment #52)
> > Please, please, please restore/return/add the ability to configure firefox so
> > that when I select/left-click 'Open All in Tabs' in a bookmarks folder, it will
> > replace ALL tabs in the CURRENT window with tabs for the bookmarks folder!
> > 
> > Setting browser.tabs.loadFolderAndReplace set to TRUE does not help.  And Shift
> > clicking creates a window.
> > 
> > For what it is worth, I am using FF 3.0.5 under OS X 10.5.6.
> 
> Can you clarify?  Unless there is something deeper involved in what you are
> requesting, or something has changed in 3.0.5, what you are describing IS
> currently what Firefox is supposed to do by default, so there isn't even a need
> for this setting anymore, except in the opposite case described in Bug 400491
> (which seems to now need revising, anyway).

I want the ability to configure firefox so that when I select/left-click 'Open All in Tabs' in a bookmarks folder, it will replace ALL tabs in the CURRENT window with tabs for the bookmarks folder.
A p.s. to comment #54:

In particular, I want the ability to configure firefox so that when I 'Open All in Tabs' in a bookmarks folder, firefox will close ALL tabs in the current window and then open a tab for each URL in the bookmarks folder.
The old behaviour (in Firefox 2) was that open all in tab, replaced all tabs. New behaviour is: replace current tab, append other tabs. See bug #440966 which I reported (it was marked as a duplicate of this bug). The old behaviour should be restored or at least there should be an option to get the old behaviour back. I'm still not used to the new behaviour, I now have to use 'close other tabs' all the time to get rid of the superfluous tabs before running 'open all in tabs'. It's annoying.
(In reply to comment #55)
> A p.s. to comment #54:
> 
> In particular, I want the ability to configure firefox so that when I 'Open All
> in Tabs' in a bookmarks folder, firefox will close ALL tabs in the current
> window and then open a tab for each URL in the bookmarks folder.

Ah, now I follow you.  I have created a separate bug report for that:    Bug 472968.
(In reply to comment #56)
> The old behaviour (in Firefox 2) was that open all in tab, replaced all tabs.
> New behaviour is: replace current tab, append other tabs. See bug #440966 which
> I reported (it was marked as a duplicate of this bug). The old behaviour should
> be restored or at least there should be an option to get the old behaviour
> back. I'm still not used to the new behaviour, I now have to use 'close other
> tabs' all the time to get rid of the superfluous tabs before running 'open all
> in tabs'. It's annoying.

Yeah, I don't even think all of that nonsense that is currently happening is even the expected behavior; I think it is a bug.  See Bug 452183 and Bug 472966.
Here's a case that use to work but no longer works:

1. Tab 1: Some page
2. Tab 2: about:blank
3. Open All in Tabs on some bookmark folder
4. Tab 2 is now overwritten

When I say loadFolderAndReplace=false I mean it. Don't even replace blank tabs.

Maybe there should be three modes to support everyone.

Add-ons are not a good answer. I can notice slow down with add-ons so I try not to add too many.
So, i'd like to get someone from UX team looking at this.

I don't think the pref is really useful, what we want is to avoid dataloss. By this i mean we should just not replace anything by default and provide a way to replace on will. SHIFT is a modifier that actually tells to replace. the pref would just say "act always as i was using shift", and that won't be much useful since it just replaces the current tab.

Also i'm not sure what's the current use-case for replacing only the last tab with a bunch of tabs. If i'm going to open a bunch of tabs and i have space limitations (that looks like the current reasoning for replace), i'd rather expect all tabs to be replaced not just the n-th one.

actually, clicking on "open all in tabs" replaces the current tab and adds new tabs, being this the easiest case i'd rather expect it to append tabs, while holding SHIFT should instead replace (what, current tab or all open tabs?)

side note: the code uses whereToOpenLinks and LoadTabs browser methods, so the behavior is common along browser interactions.
Keywords: uiwanted
As noted by Marco, the reason for replace vs. append is that we simply took the single-tab behaviour and mapped that to N bookmarks, instead of 1 bookmark:

normal     == replace current tab with this bookmark
Shift      == open in new window
Ctrl       == open in new foreground tab
Ctrl+Shift == open in new background tab

which means that for open in tabs:

normal     == replaces current tab with a contiguous set of tabs
Shift      == opens all bookmarks in a new window
Ctrl       == appends list of tabs to the end of the tab 
              list and selects the first one
Ctrl+Shift == appends list of bookmarks as new background tabs

I think we should just kill the pref out of firefox.js, I should have done that when I cleaned this up in Fx3, it's been obsolete for two major releases, and I don't see any reason to bring it back.
The single-tab behavior/keyboard shortcuts may be mapped to N bookmarks, but that doesn't hold for the menu options.

Right-clicking on a bookmark allows me to
- open
- open in new window
- open in new tab

For a bookmark folder there's only
- open all in tabs

So right now I can simply right-click->"open in new tab" for a bookmark, but have to remember the shift/control combination that forces an "open all in tabs" to behave the same (same for opening in a new window)

Things would be more coherent if a folder right-click would also propose a new tabs/new window option, i.e. something like
- open all in tabs
- open all in new tabs
- open all in new window
That's a separate bug, feel free to file that.  I don't think that we want even more items in the context menu, but we should figure out whether we care separate from this bug.
Is there some reason this can't be fixed by backing out the bug 175124 "fix", marking it INVALID, and permanently revoking the commit privileges of the perpetrators?

I'm serious.  This (well, bug 440093) is a DATALOSS bug that has gone unfixed for over a year, a sufficiently serious issue to warrant using Firefox 2.0 despite quite significant performance improvements in the 3.x series, and now I find out that the bug was introduced *deliberately*?
This behavior might be modified by some changes being considered for our bookmarks UI, where you can actually navigate on the folder itself.  So selecting the folder in the bookmarks sidebar or bookmarks toolbar would actually navigate the content area: http://blog.mozilla.com/faaborg/2009/10/13/browsing-your-personal-web/

So far not a dataloss issue since you can just hit back.  In terms of trying to open everything in the folder, I personally think these should open in addition to the current set of tabs, since opening them individually will cause them to open in addition to the current set of tabs, and it would be odd for the behavior to switch once you are acting on multiple items.
This patch deletes browser.tabs.loadFolderAndReplace from firefox.js
Assignee: nobody → michaelkohler
Status: NEW → ASSIGNED
Attachment #406351 - Flags: review?(mconnor)
So if this preference is removed, I won't be able to choose if I want to lose my data or not?  I do not want to 'Open All Tabs' and have my opened tabs replaced.
#67: This is my concern as well.

If you're removing loadFolderAndReplace, the new logic better not be replace tabs.
(In reply to comment #68)
> If you're removing loadFolderAndReplace, the new logic better not be replace
> tabs.

FYI, you can set that to any value since it's unused. Removing it does not change a bit, nor touches any logic.
(In reply to comment #69)
> (In reply to comment #68)
> > If you're removing loadFolderAndReplace, the new logic better not be replace
> > tabs.
> FYI, you can set that to any value since it's unused. Removing it does not
> change a bit, nor touches any logic.

So what is the point of this bug then?  I must be missing something.  Is the preference just not going to being exposed anymore and users will have to add it if they want to change the default value?
the pref is in prefs.js, but has never been implemented in Places. that's it.
comment 61 and comment 63 are driving here.
comment 65 could drive future.

Resolution here is to remove the pref since it's unused.
If you want to redefine default behavior for "Open all in tabs" context menu option so that it won't replace anything by default, then you should file a new bug explicitly about that.
It only became unused due to updates made to the browser. As stated near the beginning of this thread, I liked the old behavior was extremely annoyed they took it out. I would like to see it restored as an option under user preferences. This behavior and contrary what many posters have stated here may have said is a new behavior from version 2 to 3. The new behavior can remain as just as many seem to prefer. I want the load and replace option restored to the end user not cleaned out completely. There is no reason why it can't be implemented as a user decision. I find it very inconvenient how I ether have to close each of the several tabs individually carefully clicking on the small tab. I know of the shortcut to close all tabs but this too requires a precision click. So much easier to be able to have it do it automatically when I select a new folder of links to open. This was one of the reasons I was happy to switch to Firefox years ago.
Just another reminder: 
The "TabMixPlus" extension implements "replace all tabs" when a bookmark folder is opened.  I'm not affiliated with the developer in any way, just happy that I can use it to make the tool work the way I want it to.
https://addons.mozilla.org/en-US/firefox/addon/1122
Thank you! Finally a way to get the old behavior back! It's very complicated due to the many options, however, I figured it out and it gets the job done.

I don't see that the harm is in leaving a line of code that does nothing and only takes a few bytes of hard drive space. Microscopic compared to typical capacities on today's hard drives. I don't care what they do with it now as long as it doesn't break the add-on.
Comment on attachment 406351 [details] [diff] [review]
deletes browser.tabs.loadFolderAndReplace from firefox.js

r=me code wise and due to connor and faaborg directions above.

If anyone wants better default behaviors, single bugs should be filed for each of them with clear reasons.

You should recall that Firefox aims to be a browser adapt to anyone, but since we have hundreds millions of users, we can't satisy everyone (extensions are there for a purpose).

also there are workarounds, either choose "close other tabs" in the right click tab menu and then open in tabs, or you can also shift+click on a container to open in a new clean window, and close the old window.
Attachment #406351 - Flags: review?(mconnor) → review+
Summary: support browser.tabs.loadFolderAndReplace or browser.tabs.loadFolderAndReplace obsolete, remove it from firefox.js → browser.tabs.loadFolderAndReplace is obsolete, remove it from firefox.js
Keywords: uiwanted
Thanks Michael.
http://hg.mozilla.org/mozilla-central/rev/4bdd32236726

please notice bug 440093 is still alive and valid.

If you have further comments please open a discussion in moz.dev.apps.firefox, don't spam bugs, since the cleaner they are the faster they move on.
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3.7a1
Flags: in-testsuite-
I made an extension just for this setting to return, it might be useful to someone who prefers the old behavior: https://addons.mozilla.org/nl/firefox/addon/8511?src=reco
Also, I've attached the bug here: https://bugzilla.mozilla.org/attachment.cgi?id=384615 to bug 175124.
> So far not a dataloss issue since you can just hit back.

We're talking about a situation where an entire bookmark-folder full of tabs was just opened.  By the time the user realizes that *one* of them replaced the contents of a pre-existing tab, he's already closed all the new tabs, probably starting with the one where he'd need to hit back.

After I noticed that I was losing tabs at random, it took me the better part of a week to track down that it was happening one at a time whenever I opened a tabset.

This (well, but 440093) is without question most definitely a dataloss issue.
Doesn't exist anymore in firefox.js:
http://mxr.mozilla.org/mozilla-central/source/browser/app/profile/firefox.js

Verified with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.3a1pre) Gecko/20091021 Minefield/3.7a1pre ID:20091021030944

Marco, is it worth asking for approval1.9.2?
Status: RESOLVED → VERIFIED
No, it's just cleanup, I think we're done here.
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
Component: Places → Bookmarks & History
QA Contact: places → bookmarks
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: