Closed Bug 216346 (RemovesExistingTabs) Opened 21 years ago Closed 17 years ago

"Open in Tabs" overlays/removes/overwrites/replaces existing tabs

Categories

(Firefox :: Bookmarks & History, defect)

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

Tracking

()

Status:
RESOLVED DUPLICATE of bug 175124

People

(Reporter: keefedm, Assigned: p_ch)

References

(
URL
)

Details

Attachments

(1 file)

Patch to invert the current default behavior
715 bytes, patch
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5a) Gecko/20030728 Mozilla Firebird/0.6.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5a) Gecko/20030728 Mozilla Firebird/0.6.1

Invoking Open in Tabs option from Bookmarks Folder context menu overlays/removes
existing tabs.  This can be very annoying (especially if one of the tabs blown
away was a form with unsaved data in it -- say a bug report, for instance). 
Better for option to open pages as new/additional tabs.

Reproducible: Always

Steps to Reproduce:
1.  Create/arrange bookmark folder with small number (say 2) bookmarks in it.
2.  Open larger number (say 3) other pages in tabs.
3.  Invoke Open in Tabs option from context menu of aforementioned folder.

Actual Results:  
Previously opened (3) tabs were gone; only 2 tabs from folder remained.

Expected Results:  
Folder bookmarks should have been added as new tabs.  Final result would be the
3 original tabs followed by the 2 new tabs.
browser.tabs.loadFolderAndReplace defaults to true.  If you want the behaviour
you specified, change this pref.

As this is starting to show up more and more, I should talk to blake about
adding this to the advanced prefs panel.

In any case, there is a pref available, so the bug as it stands is invalid.
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago
Resolution: --- → INVALID
*** Bug 233450 has been marked as a duplicate of this bug. ***
*** Bug 246795 has been marked as a duplicate of this bug. ***
re-opening with the 0.9 release; for the default behavior was this, but between
0.8 & 0.9 at some stages it switched such that existing tabs weren't wiped. I
personally see this as a major bug - it's unexpected behavior, and really needs
to be clarified either by an option in preferences, or by defaulting it to true.
Severity: minor → normal
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
sorry for the spam - should read "befor the default behavior was this"...
Status: UNCONFIRMED → NEW
Ever confirmed: true
don't reopen ancient bugs.  File a new bug, but as far as I can tell, we didn't
change the pref.
Status: NEW → RESOLVED
Closed: 21 years ago → 20 years ago
Resolution: --- → INVALID
*** Bug 248429 has been marked as a duplicate of this bug. ***
*** Bug 271564 has been marked as a duplicate of this bug. ***
(In reply to comment #8)
> *** Bug 271564 has been marked as a duplicate of this bug. ***
I don't think this is duplicate because I am talking about firefox 1.0 and there
is a pref in the advanced options, but it doesn't work. There may be a way to
edit a text file somewhere to force this pref to false but surely the bug is
that the pref in the advanced options should actually work. It's a fairly major
part of the browser functionality, very easily replicated, so surely it is best
if one of you guys are kind enough (I am appreciative of all the work that you
people have put in to this browser) to fix this prob once and for all. All the
mere mortal windows users who we are hoping will defect to this browser, won't
know that or how they should edit some file to fix this, and I want firefox to
kick M$IE's butt not have irritating bugs with obscure workarounds. 


That pref doesn't do what you think it does.  It dictates whether new tabs are
selected (focused) or opened in the background.  It has nothing to do with the
append/replace behaviour of opening a set of tabs.
*** Bug 244871 has been marked as a duplicate of this bug. ***
*** Bug 246094 has been marked as a duplicate of this bug. ***
*** Bug 250236 has been marked as a duplicate of this bug. ***
*** Bug 250240 has been marked as a duplicate of this bug. ***
*** Bug 259865 has been marked as a duplicate of this bug. ***
*** Bug 261730 has been marked as a duplicate of this bug. ***
*** Bug 278468 has been marked as a duplicate of this bug. ***
*** Bug 267388 has been marked as a duplicate of this bug. ***
*** Bug 267280 has been marked as a duplicate of this bug. ***
Status: RESOLVED → VERIFIED
*** Bug 259849 has been marked as a duplicate of this bug. ***
Alias: RemovesExistingTabs
(In reply to comment #1)
> browser.tabs.loadFolderAndReplace defaults to true.  If you want the behaviour
> you specified, change this pref.
> ...
> In any case, there is a pref available, so the bug as it stands is invalid.

I argued against the position that just because there is a preference, this
isn't a bug, in bug 259865 comment #2, which has since been marked a dupe of
this bug. 

I strongly suggest reopening this as valid.

I also summarized some of the history of this bug in that comment, which I'm
referencing here so that it doesn't get lost from the thread.

We can change this to WONTFIX, but the end result is the same.  Its been
discussed a number of times, and we're happy with the default staying as it is.
(In reply to comment #22)
> We can change this to WONTFIX, but the end result is the same.  Its been
> discussed a number of times, and we're happy with the default staying as it is.

(In reply to comment #21)
> (In reply to comment #1)
> > browser.tabs.loadFolderAndReplace defaults to true.  If you want the behaviour
> > you specified, change this pref.
> > ...
> > In any case, there is a pref available, so the bug as it stands is invalid.
> 
> I argued against the position that just because there is a preference, this
> isn't a bug, in bug 259865 comment #2, which has since been marked a dupe of
> this bug. 
> 
> I strongly suggest reopening this as valid.
> 
> I also summarized some of the history of this bug in that comment, which I'm
> referencing here so that it doesn't get lost from the thread.
> 

What is the pref that's available? Perhaps more specifically, how does one set
browser.tabs.loadFolderAndReplace defaults to true? -Greg
*** Bug 279125 has been marked as a duplicate of this bug. ***
(In reply to comment #23)
 
> What is the pref that's available? Perhaps more specifically, how does one set
> browser.tabs.loadFolderAndReplace defaults to true? -Greg

1. type about:config in the address bar
2. in the filter paste "browser.tabs.loadFolderAndReplace"
3. double click on the item to change it from true to false

OR

1. create a user.js file in your profile directions @
http://www.mozilla.org/support/firefox/edit#user
2. past the following into the file
// Force browser to use new tabs instead of reusing existing ones.
user_pref("browser.tabs.loadFolderAndReplace", false);


*** Bug 252139 has been marked as a duplicate of this bug. ***
*** Bug 280983 has been marked as a duplicate of this bug. ***
*** Bug 285143 has been marked as a duplicate of this bug. ***
With all due respect, I disagree with the consensus decision to leave this
default behavior as-is, even if there is a (somewhat obscure) pref to change it.

It is totally non-intuitive behavior from a human interface standpoint.

Look, if I have both "Open links from other apps in: a new tab in the most
recent window" and "Select new tabs opened from bookmarks or history" chosen, I
find it totally unexpected that "Open in Tabs" should somehow close all my
existing tabs to do its thing. Especially since this occurs without any warning
OR any way to get those tabs back.

I submit that the correct behavior is to follow the setting of the "new tabs
opened from bookmarks or history" checkbox under the Tabbed Browsing pref. 
*** Bug 288039 has been marked as a duplicate of this bug. ***
*** Bug 291990 has been marked as a duplicate of this bug. ***
*** Bug 300194 has been marked as a duplicate of this bug. ***
Currently, middle-clicking on an item in the bookmarks toolbar will open all its
contents in separate tabs. While doing this, it replaces the contents of all
current tabs, and closes tabs it does not need. I do not think this behavior is
desirable, for the following reason:

There have so far already been multiple occasions where I have, with the
intention of middle-clicking on a tab to close it, accidentally middle-clicked
on the bookmark folder above it, causing all my tabs to be replaced with the
contents of the bookmark.

For the tabs that remain afterwards, I can revert them to their original
location by going through them one by one and going back 1 position in the
history, but for the tabs that I had in excess to the number of bookmarks in the
folder, they are lost.

I do believe this should not be possible, everytime this happens it gives me a
lot of frustration, and this issue falls into the same category as to why there
are no ‘close buttons’ on the tabs.

Middle-clicking on top-level folders in the bookmarks toolbar should either:
1. Do nothing;
2. Open in *NEW* tabs instead of replacing the current ones;
3. Not close tabs in excess.

Personally, I never use the "middle-click to open multiple tabs" feature, so as
far as I am concerned, solution 1 is the most desirable. Given however that
there will probably be complaints for the loss of functionality solution 2 would
also be good. Solution 3 is sub-optimal, but better than nothing.


~Grauw
p.s. please consider the huge amount of duplicates on this issue.
Here is a patch to invert the current behavior, into the least destructive
variant.

As for people who desire the current behavior, I think they can be considered
as ‘power users’, who can be facilitated by letting them change this
preference.


~Grauw
FYI, as this bug has been resolved as INVALID per the rationale "there is a pref
available, so the bug as it stands is invalid", I have created a new bug to
specifically address the default setting of that preference: bug 300198.


~Grauw
*** Bug 300606 has been marked as a duplicate of this bug. ***
*** Bug 300632 has been marked as a duplicate of this bug. ***
*** Bug 301434 has been marked as a duplicate of this bug. ***
*** Bug 308826 has been marked as a duplicate of this bug. ***
*** Bug 309621 has been marked as a duplicate of this bug. ***
Summary: Open in Tabs Overlays/Removes Existing Tabs → "Open in Tabs" overlays/removes/overwrites/replaces existing tabs
*** Bug 320580 has been marked as a duplicate of this bug. ***
*** Bug 333077 has been marked as a duplicate of this bug. ***
I filed bug 333077 which was then marked as a duplicate of this, and want to register agreement with Laurens Holst. 

To delete lots of my data (tabs, forms, email tabs, etc), without warning me, against all the visible preferences that can be set (emphasis: visible), without an Undo, is madness. Read the Apple user interface manual of the late 1980s for instructions to the contrary, if you must. Sure, if ultra-power users want this behaviour, more fool them and they can set that themslves, but ordinary folk surely don't want it (as witnessed by numerous duplicates). 

The fix is trivial: change the default value of this setting, and let power users do as they please. Please? 
Right now I actually keep the Web Developer toolbar open all the time, because it sits between the tabs and the bookmarks toolbar, and it is thus less likely for me to accidentally click on the bookmarks toolbar.

Heh.


~Grauw
Mike Connor seem to be suggesting that this bug has been discussed, and that the conclusion was that it wouldn't be fixed ("Its been discussed a number of times, and we're happy with the default staying as it is.") Could anyone point me in the direction of this discussion? I know from the points raised here that it's only a matter of setting a preference, but my point is that the 'bug' is that the default behaviour is 'wrong'.

The text in question reads "Open in tabs" - I certainly didn't expect it to mean "Open in tabs that you already had things in, and close any surplus tabs you had open, without warning". This is destructive behaviour, and in my opinion it shouldn't be the default unless there's a really good reason for it; if such a justification exists, I think it should be pointed to here.

Thanks,
Jim
It is probably a good idea to start a discussion on one of the newsgroups about this. Maybe it can then be discussed more openly, with a more sensible outcome.


~Grauw
Hi all,

This bug is at best very annoying, and at worst causes data loss. To prevent this very annoying behaviour, I had to search a bug database, read the comments on this bug, go to the magical 'about:config' page, and edit a setting that does not seem to be documented anywhere. I doubt very much that the (mythical) 'average user' would be able toggle this setting.

I agree with the 20 odd people who have filed bugs about this - the default behaviour is poor, and needs to be fixed.

browser.tabs.loadFolderAndReplace should default to false.

Thanks,

-Marc
*** Bug 338414 has been marked as a duplicate of this bug. ***
From #338414


You cannot have this a default behaviour.  Nobody who clicks something like "Open in tabs" will expect all their current tabs to disappear. 
They expect the bookmarks to "open in tabs", NEW tabs. 

These rare people who actually like this behaviour can go and set the appropriate preference. You can't have a destructive behaviour as a default without warning the user or anything.

What is the next thing, clicking "Print" will delete all your bookmarks?

Reading this thread and discovering that middle-click on a bookmark folder does the very same thing scares me even more. I am getting afraid to use Firefox for anything important.


Simon Bunzli replied me in #338414:

> Please take a deep breath and accept that this issue won't be fixed. 
> As a work-around, either set the hidden pref 
> browser.tabs.loadFolderAndReplace to false (in about:config) 
> or get yourself a tabbed browsing extension.


How can you require all users (including novices) to go to some fancy property to avoid that when they click on an action to "open" everything else will close?

Why can't those who really want their session to be destroyed be the ones to install weird plugins and preferences?
*** Bug 338414 has been marked as a duplicate of this bug. ***
*** Bug 345727 has been marked as a duplicate of this bug. ***
*** Bug 348749 has been marked as a duplicate of this bug. ***
sorry for bugspam, long-overdue mass reassign of ancient QA contact bugs, filter on "beltznerLovesGoats" to get rid of this mass change
QA Contact: mconnor → bookmarks
*** Bug 351288 has been marked as a duplicate of this bug. ***
*** Bug 351635 has been marked as a duplicate of this bug. ***
*** Bug 351635 has been marked as a duplicate of this bug. ***
*** Bug 351635 has been marked as a duplicate of this bug. ***
*** Bug 351635 has been marked as a duplicate of this bug. ***
*** Bug 358020 has been marked as a duplicate of this bug. ***
*** Bug 358643 has been marked as a duplicate of this bug. ***
*** Bug 358627 has been marked as a duplicate of this bug. ***
öCannot we do a poll to see that more 95% of poeple would like this setting to be false by default??

Or do we have to recompile firefox with that option setted to false and redistribute it somewhere else?


öCannot we do a poll to see that more 95% of people would like this setting to be false by default??

Or do we have to recompile firefox with that option setted to false and redistribute it somewhere else?


Three new duplicates in the last few days - yet nothing is done with this bug except closing the duplicates. How can we take this process somewhere where anything can actually be done?

(In reply to comment #65)
Well, according to http://www.mozilla.org/hacking/module-ownership.html you could try to escalate decision making from the module owner who INVALIDated this bug to Mozilla.org staff <staff@mozilla.org>.

The problem is that the decision is said to be based upon an undisclosed usability study (see bug 243740) which probably is already known to staff, whereas you yourself don't even have any empirical data to support the change requested here (except of a vocal minority filing the occasional bug).
So you think that we should email staff@mozilla.org about that issue?

I think we can request that they do a poll on Mozilla.com or wherever else ... 
Then they can know the real opinion of Firefox users around the world and right decision can be made then ..


No, Firefox UI decisions are generally not made based on polls, since out of the however many million Firefox users there actually are, your poll will reach the few hundred or thousand who are actually looking for something different. And the odds of staff@ overruling a Firefox UI decision are equally microscopic.

The actual useful steps to take when you disagree with a Firefox UI decision are:

1. Understand completely why the decision was made the way it was. You have no chance of changing it if you don't know what the current behavior is intended to allow. In this case, even though you don't get to see the mythical usability study, you still have to understand the alternate way of using bookmark groups, to change completely from one task using one set of tabs to another task using another set of tabs, to have any chance of proposing something that will work better for both uses.
2. Find a way to minimize or eliminate the impact of the change you want on the current behavior.
3. Make your proposal on http://groups.google.com/group/mozilla.dev.apps.firefox and then bring it to Bugzilla once you've gotten some developer agreement.

I know it seems rude and stupid that the developers make bad decisions and then ignore people complaining about them in old closed bugs, since I'm in the same position you are on other bugs, but that's just the way it is: for you and for me, there are a few horribly annoying bugs about which a stupid decision was made, but for any developer who has been around long enough to have any decision making power, there are hundreds of bugs just like this where a decision had to be made, and some people would disagree either way, and the only way you can get out of the "expected disagreement, too bad" category is to clearly be calm and reasonable and have an understanding of the whole situation and to do your arguing in an appropriate place for an appropriate thing.
Let's take for granted that there are users who want this feature. Let's also take for granted that there are users who neither expect nor want this (probably more, but that's not even the point). Now we do have a pref, it can be toggled. This is true for both groups.
Do all users know about this pref? No. True for both groups again.
Will on/off by default annoy one of the groups? Yes, true either way.
Who will be annoyed most? Those who lose their tabs. So it comes down to data loss. Nobody likes it. "Off by default" wins with one leading point.

This is pretty simple. I have a hard time understanding the given situation.

Some additional notes on data loss (and why it has to be called data loss):
1. Not everybody will realize that tabs were not really closed and going back is possible.
2. Going back cannot restore everything.
3. If there were more tabs than bookmarks, some are closed.
4. Re-opening "Recently Closed Tabs" cannot restore everything.
5. Not everybody knows about History -> Recently Closed Tabs.
6. If there are more than 10 tabs closed, they get lost. (This happened to me.)
*** Bug 361725 has been marked as a duplicate of this bug. ***
FYI: Workaround for this behavior is at http://kb.mozillazine.org/Browser.tabs.loadFolderAndReplace
How can this be Invalid?

This is a serious data-loss issue! (esp. when the user has some kind of web app open that just vanishes)

All default settings have to go for safety, and this is definitely not.

please reconsinder
It's very disappointing ...
I agree with all of the other users here.  Just because a handful of developers "think" that is what the masses want, that is incorrect.  If I have 4 tabs open, and I want to open a folder of tabs, why would I want to have all of my other tabs closed?  Couldn't I close them manually if I did not want them?

The thing that really **** me off is that sometimes you have several tabs open for research and you have no way of knowing where you are or how you got there.  Sure you can use the recover closed tabs, but how many browser smart people are there?  I like to think I am, but I should not have to go into the about:config to fix a setting that is obviously defaulted wrong.

Why don't you poll users to see what the desired effect is?
I just don't see why this isn't a bug. If I want to open more tabs... who says I want to close existing ones?
If this is not going to be fixed, then a checkbox for this option should be added to "Options -> Tabs".
A large number of duplicates speak for themselves.
I really think that there must be some thing we can do to change that ... 
I think that developers at Mozilla Org. are really great people but they can make some wrong decision sometimes ... so there should be a way to correct those decisions ... 
And it is inconstant with normal Bookmamrks. 
Middle Click on a normal bookmark -> new tab is opened, current tab stays.
Middle Click on a bookmark folder -> *all* current tabs are replaced.
Good point, Matthias.
If simple logic is not enough to mark this problem as a bug, maybe the behaviour  of tabs described in your comment is. 
(In reply to comment #78)
> Good point, Matthias.
> If simple logic is not enough to mark this problem as a bug, maybe the
> behaviour  of tabs described in your comment is. 
> 

I've filed Bug 365244, which covers a bit more than just this issue, since middle clicking on a normal link is also different from middle clicking on a bookmark item.

Yet another duplicate... Maybe this really IS a bug?
(In reply to comment #77)
> And it is inconstant with normal Bookmamrks. 
> Middle Click on a normal bookmark -> new tab is opened, current tab stays.
> Middle Click on a bookmark folder -> *all* current tabs are replaced.
> 

That is a good point. I hesitate to agree with the default behavior, but I'm more hesitant to allow discrepancies like that. Perhaps, a dialog box? "Warning, this action will overwrite established tabs. OK? Check HERE if you don't want to see this again. Check HERE if you want new tabs.

This is invalid because it was the intended behavior. Discussion on changing the intended behavior is happening in Bug 175124,although I believe once a new behavior is set in stone, a new bug will be filed on implementing it (which this one will probably be duped to, since most people's point in this is asking for a different behavior)
URL: https://bugzilla.mozilla.org/show_bug...
If opening a regular bookmark opens new tabs, opening several bookmarks should open several new tabs. If there is any controversy, which their obviously is, it should be a check box, either one in the Preferences or one in a dialog the first time you lose all your tabs asking you which way you want it and whether or not to make that YOUR Fx's behavior, like with saving passwords on a particular website. Firefox is supposed to be about choice. About:config is not a choice for the end user.
Discussion is not happening in this bug.  Please refer to the bug I mentioned (and added to the URL field).
I'm not sure why discussion should be prevented in this bug - it's actually the better-named of the two bugs. The real issue here is that the current default behaviour is destructive, which is what is described by the title in this bug. The title of bug 175124 ("Implement Camino style opening tabs replace as necessary functionality") is just proposing one (of at least three) solutions to this bug.

* Having two locations for this discussion is not helpful. I think one of them should be duped to the other.
* This bug's title describes the problem, not just one potential solution to it.
* This title is more likely to be found by those 'discovering' the bug for the first time.

I'll try to pull together all the potential behaviours that have been listed on both bugs:

* 'Replace' - current behaviour, replacing all open tabs with the new tabs.
* 'Smart Replace' - replaces tabs, but leaves excess tabs alone.
* 'Replace One' - replaces just the tab that you are focused on, slotting all new tabs in that position. (i.e. if you're on tab B with A, B, C, you get A, D, E, F, C)
* 'Append' - add the new tabs on the end of the open tabs.

I hope that covers most of the bases. My personal opinion is that Replace is destructive, and that Smart Replace and Replace One are potentially confusing to the user, but at least non-destructive (because you can use the back button).

The current proposal on the other bug (which actually doesn't match the title of that bug) is:

* Middle clicking either the Open All menuitem or the folder will Append.
* Left clicking the Open All in Tabs menuitem will Replace One.
* Context menu option will behave in line with left-click.

Hope that little round up is useful for someone.
because it's wasted here.  The devs aren't going to follow 5 different conversations in x number of places, let a lone in a bug marked invalid.  If you care about participating in the discussion, participate where the active discussion is taking place.

Yes I know the title doesn't match the current proposal, that's the part where I was talking about a new bug being filed once the plan is set.
bug 175124 doesn’t describe new behaviour, but the current behaviour. I don’t know why it exists.

Also, discussion is NOT taking place in that bug but in the dev.apps.firefox newsgroup. Anyway, his suggestion that he cross-posted in bug 175124 sounds good.

~Grauw
(In reply to comment #89)
> because it's wasted here.  The devs aren't going to follow 5 different
> conversations in x number of places, let a lone in a bug marked invalid.  If
> you care about participating in the discussion, participate where the active
> discussion is taking place.
> Yes I know the title doesn't match the current proposal, that's the part where
> I was talking about a new bug being filed once the plan is set.

Wasted here?  Am I missing something?  We have 90 comments from people in this thread, and there are only what 20 in yours?  And active discussion?  You have had 20 posts in 5 years.  There have been 90 in 4 here (and more recently).

As soon as you "get your plan" together and start a new topic that makes sense to the masses, feel free to post it here.  Until then, do something constructive with your time.  
Along the same lines as Fx 2.0 being an ease-of-use and ease-of-looks release, opening in tabs the recently closed tabs creates new tabs...
Given the plan mentioned in [1] (which sounds like a great plan), I think this bug can be re-opened? As it’s clearly not invalid.


~Grauw

[1] http://groups.google.com/group/mozilla.dev.apps.firefox/msg/63dc46fb5f211ddb
Laurens - see comment #85

The bug can be reopened, but it'll just be waiting to be duped. I think we want to leave this closed until it can be duped to encourage people to find the bugs/newsgroups where work will actually take place.
I wonder just how many duplicates it will take to get someone to take this seriously? Maybe after 100+ dupes?
I don't this 100+ is enough for them to care about it. I think they need a public petition with more than 1 million signs ... !!!!!

Please care !! People are losing data!  
Please read the whole bug before commenting, especially the URL field at the top.
the URL field doesn't contain any thing!
... it does for me.  It'll also take you to that url if you click on it. https://bugzilla.mozilla.org/show_bug.cgi?id=175124

If you really can't see it it'd be great if you can take a screenshot of the page with the empty field and we can start looking into why.
Thanks man .. I though the URL itself should appeared completely at the URL field ... 
I recognized that I should clock on the "URL" word itself .. 
I was on the way to report the same bug but saw that its already reported here. Also i changed the pref browser.tabs.loadFolderAndReplace to false. Cant understand why its enabled by default and i have to loose tabs and wondering whats going on.

If i want to close tabs there is close button that i can use but to close tabs so unexpectedly is bad idea. If anyone didnt experienced that he have no idea what will happen.

Anyway thanks for the pref. At least there is a way to prevent that and making this pref to false by default would be better.
Status: VERIFIED → RESOLVED
Closed: 20 years ago → 17 years ago
Resolution: INVALID → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: