improve open in tabs behaviour

VERIFIED FIXED in Firefox 3 alpha8

Status

()

Firefox
Bookmarks & History
P2
enhancement
VERIFIED FIXED
15 years ago
7 years ago

People

(Reporter: Anoop Ranganath, Assigned: mano)

Tracking

Trunk
Firefox 3 alpha8
Points:
---
Dependency tree / graph
Bug Flags:
blocking-firefox3 +
in-litmus +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments, 5 obsolete attachments)

(Reporter)

Description

15 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20021014 Phoenix/0.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20021014 Phoenix/0.3

Currently Phoenix offers replace and append functionality for tabs and
groupmarks.  Both of these are not ideal because replace is destructive and
append is cluttered.

Chimera deals with this issue by using the existing tabs whenever possible, and
appending additional tabs if the number of tabs in the groupmark is greater than
the number of open tabs.  The action is not destructive because the user can use
the back button in all of the existing tabs to access previous pages, and it is
not cluttered because at most, you either have as many tabs open as you already
had or you have as many tabs open as are in the groupmark you selected.

Personally, I think this solution is the most ideal compared to replace and
append, and could be the only solution as it doesn't suffer from either of their
pitfalls.  It should at least be included as an option.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

15 years ago
Seams like a valid request for enhancement. Marking as enhancement and setting
as NEW.
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

15 years ago
Summary: enable Chimera style groupmark/tabs functionality → implement Chimera style opening tabs replace as necessary functionality

Comment 2

15 years ago
Tabbed Browsing Extension seems to offer this.
(Reporter)

Comment 3

15 years ago
I installed the Tabbed Browsing Extension, and there doesn't appear to be any
difference.  I've tried all the settings and can't reproduce the way Chimera
handles tabs.  Could you detail settings to do this?

Updated

14 years ago
Whiteboard: asa:ui

Updated

14 years ago
Target Milestone: --- → Firebird0.8

Comment 4

14 years ago
See also bug 208278, same or similar bug for Seamonkey.

Updated

14 years ago
QA Contact: asa

Comment 5

14 years ago
please see also #195212
,thx

Comment 6

14 years ago
I think this needs to be an option, as there are many situations in which a user
might want to open multiple copies of a tab by Ctrl+clicking a link multiple times.
-> 0.9
Target Milestone: Firebird0.8 → Firebird0.9

Comment 8

14 years ago
Agreeing with #6 that this should only be implemented as an option.  I often
keep a page or two open that I plan to return to, but open a group because I'm
also looking into something else.  "Out of sight, out of mind", and therefore
I'd lose the information on the original page.

Comment 9

14 years ago
This bug seems as though it would be relatively easy to fix, however I'm
hesitent to try because of comments in bug 173406 suggesting that new options UI
for tabs is undesirable. It doesn't really make sense to me to have UI to turn
on this preference but not for the load vs. append option (what would this
option mean when in append mode? Nothing?).

It seems logical to me to re-add the Advanced > Tabbed Browsing category,
although I guess that option has been pretty thoroughly defeated. Underneath
that would go the current "Hide tab bar" and "Open links in background" prefs,
plus a new one along the lines of "Open bookmark groups in existing tabs" which,
when checked, would have a sub-option "Close unused tabs" available. Probably
not that exact wording, but you get the idea.

In that scenario, checking the first checkbox and un-checking the second would
turn on the behavior requested in this bug. Unchecking the first box (which
would automatically disable the sub-option) would enable the append mode, and
checking the first and second boxes would enable replace mode.

Does this make sense? Should I bother trying to code this, or will it get shot
down as too much confusing bloat in the options panel? Alternatively, a pref
with no UI could be added, although in that case relatively few people would
ever use the feature.

Comment 10

14 years ago
I think the problem here is this:

At the moment if you open a group of tabs when you have fewer than the number of
tabs in the group already open, Firefox reuses the existing tabs and creates as
many new ones as neccessary to open all the tabs in the group. This is the
desired situation as there is no data loss - the user can press "Back" on
pre-existing tabs to go back to information they had before if they need it.

The problem is if you have, say 10 tabs open and you open a group with, say, 3
tabs in it. Firefox will then reuse the first 3 tabs but CLOSE THE OTHER 7. This
results in dataloss. The desired situation would be Firefox reusing the first 3
tabs and leaving the rest as they are.

None of this requires a pref.

Comment 11

14 years ago
I am personally very happy with the Append mode.  But I agree that replace
should not delete open tabs that aren't used by the new operation.

I would also like to see the Append mode changed (or option to) allow the
replacement of the current tab and appending the rest.  Or perhaps replace the
current tab when there is only one tab.  I frequently open a lot of tabs, then
close them one at a time as I view them.  Left with the last tab I then open
more, and have to return to the first and close it.

Also the "open in background" option only seems to work with individual tabs
opened with middle mouse click.  Ctrl-T and bookmark groups change focus
unfortunately.

Comment 12

13 years ago
(In reply to comment #10)
> The problem is if you have, say 10 tabs open and you open a group with, say, 3
> tabs in it. Firefox will then reuse the first 3 tabs but CLOSE THE OTHER 7. This
> results in dataloss. The desired situation would be Firefox reusing the first 3
> tabs and leaving the rest as they are.

I think this statement hits the problem on its head. Firefox is targeted at
relatively non-advanced users who just want a simple tool to browse the Web.
Such users would be terribly distraught if they lose their tabs because (I
believe) they wouldn't have thought of (a) memorizing the URL, or (b)
bookmarking the URL before opening the new group.

If no new options are to be added for tabbed browsing, then I believe this
should be the default implementation.

(BTW I've been using Mozilla since pre-1.0 days (milestone 10?) and also have
browsing experience with IE, Opera and Safari. I use a Macintosh at home and
Windows at work.)
Target Milestone: Firefox0.9 → After Firefox 1.0

Comment 13

13 years ago
(In reply to comment #10)
> The problem is if you have, say 10 tabs open and you open a group with, say, 3
> tabs in it. Firefox will then reuse the first 3 tabs but CLOSE THE OTHER 7. This
> results in dataloss. The desired situation would be Firefox reusing the first 3
> tabs and leaving the rest as they are.

It would avoid dataloss but how the user is supposed to know that only the 3
first tabs were used to opened the new tabs ?

I think we should stick to simplicity, we're also trying to fix this weird
behaviour with bug 241305.

My idea is that the middle clicking folder feature behaviour should be the same
as the middle clicking bookmark one. You middle click a bookmark, it opens a new
 tabs, it doesn't use the first tab nor close all the tabs to open the tab. So
middle clicking a folder should open new tabs, not using the existing tabs nor
closing them.

Comment 14

13 years ago
This should be a third pref. We should have "append", "replace", and "smart
replace" where smart replace is just like replace but we don't discard tabs when
the new set is smaller than the previous set. 

Comment 15

13 years ago
...and smart replace should be the default for FireFox 1.0, IMHO.

Comment 16

13 years ago
(In reply to comment #15)
> ...and smart replace should be the default for FireFox 1.0, IMHO.

Firefox closed again 15 of my opened tabs because of my middle-clicking mistake
and even using Firefox 1.0 Preview Release, there's no way I can get my tabs
back. I noticed there was a new « Warn when closing multiple tabs » checkbox in
the advanced options but as mentionned in the 258224 bug, it has no effect on
the middle-clicking bookmark feature.

I hope we will be able to select between append, replace and smart replace as I
don't think any end-users would like to go back its tabs nor guess which ones
were replaced by the news ones... The first ones or the last ones, from the left
or from the right ?

I still believe the most and only logicial middle-click behaviour is to append
the tabs to the existing ones. User middle-clicks a bookmark to open it to a new
tab, so they logically expect a folder to open in new tabs too, not in the
existing ones.

Using two different behaviours for folders and bookmarks wouldn't make any sense
to the user.
Component: General → Tabbed Browser
Flags: blocking-aviary2.0?
Target Milestone: Future → ---
Assignee: firefox → nobody
QA Contact: tabbed.browser

Updated

12 years ago
Flags: blocking-aviary2? → blocking-aviary2+
Assignee: nobody → bugs.mano
Priority: -- → P2
Summary: implement Chimera style opening tabs replace as necessary functionality → Implement Camino style opening tabs replace as necessary functionality
Target Milestone: --- → Firefox1.6-
Status: NEW → ASSIGNED
OS: Windows 2000 → All
Hardware: PC → All
Version: unspecified → 1.5 Branch
Blocks: 221445
Beltzner and I discussed this at length a couple weeks ago, I'll try to get that discussion written down and in this bug.
I would be interested in reading said discussion, as I am implementing a new feature in TBP 1.3.0 which addresses bug 195212 and probably this one too.

Updated

12 years ago
Assignee: bugs.mano → mconnor
Status: ASSIGNED → NEW
Target Milestone: Firefox 2 → Firefox 2 alpha2
(In reply to comment #17)
> Beltzner and I discussed this at length a couple weeks ago, I'll try to get
> that discussion written down and in this bug.

Boy, I hope you still remember what we said, 'cause I don't. ;)

Updated

11 years ago
Whiteboard: asa:ui → SWAG: 2d

Updated

11 years ago
Target Milestone: Firefox 2 alpha2 → Firefox 2 beta1

Updated

11 years ago
Flags: blocking-firefox2+ → blocking-firefox2-

Comment 20

11 years ago
Any action on this? We really ought to do something before Fx2 comes out, given it's focus on UI polish and the counter-intuitive dataloss that is currently the default.

I believe even the Camino approach would lead to some dataloss, as it will be all too easy to close one of the "new" tabs without realising that one of your previous tabs was buried in its history. Simply changing the default to append would be simpler, safer, and less of a problem now that tab overflow is managed.

Comment 21

11 years ago
Bug #216346 shows lots of requests to make "append" the default behaviour as people don't expect all their tabs to be replaced or closed.

Comment 22

11 years ago
removed SWAG: 2d from status whiteboard since that was added back in march and obviously isn't being worked on plus the bug was marked blocking-firefox2 3 months later. Setting accordinly for 3.0 request.  Weird that I can't request blocking-firefox3 though?
Whiteboard: SWAG: 2d
Target Milestone: Firefox 2 beta1 → Firefox 3 alpha1
Version: 1.5.0.x Branch → Trunk
Duplicate of this bug: 366741
mconnor - remembered the plan yet?
We should:

 - remember our brilliant plan (this probably means recreating that conversation, but this time, when we ask "should we right this down", we'll go to Page 33 instead of Page 14 and be able to continue to Choose Our Own Adventure)

 - resolve this once and for all

For Firefox 3.
Flags: blocking-firefox3?
Assignee: mconnor → mano
Component: Tabbed Browser → Places
Flags: blocking-firefox2-
QA Contact: tabbed.browser → places
Target Milestone: Firefox 3 alpha1 → Firefox 3
Reposting from dev-apps-firefox:

Key points:

* Middle-click is consistently open in new tab throughout the UI (with the notable exception being closing tabs)
* Left-click replaces the current tab for every UI action that loads a new URL
* Old behaviour needs to be available for old fogeys like me.
* Middle-click == Accel+click in all cases

Random notes:
* IIRC, middle click on the feed icon/menu doesn't preview/subscribe (in the always use web reader case) in a new tab.  We might have fixed this late in Fx2, but I don't remember.  If not, we should fix that.  Search has a bug on this that we should fix.

The Great and Irrefutable Draft Plan (please feel free to refute)

* Middle clicking either the Open All menuitem or the folder will append the tabset to the current tabs
* Left clicking the Open All in Tabs menuitem will replace the current tab with the selected tabset (i.e. if you're on tab B with A, B, C, you get A, D, E, F, C, just like the homepage button does)
* Context menu option will behave in line with left-click.

Updated

10 years ago
Flags: blocking-firefox3? → blocking-firefox3+

Updated

10 years ago
Target Milestone: Firefox 3 → Firefox 3 alpha6

Comment 27

10 years ago
Just for kicks (and reference), I use the Tab Clicking Options along with Duplicate Tabs extensions to help here, or at least did before Suiterunner. I think it installed, but I haven't had a chance to test it completely yet.

from here: http://twanno.mozdev.org/

Updated

10 years ago
Target Milestone: Firefox 3 alpha6 → Firefox 3 beta1

Updated

10 years ago
Target Milestone: Firefox 3 M7 → Firefox 3 M8
Created attachment 274257 [details] [diff] [review]
needs a bit of cleanup

obsoletes the old prefs by making the modifiers sane (middle click always appends)

Also implements support for Shift-clicking the open in tabs menuitem to open the tabset in a new window, and fixes the old xxx about open in tabs not working with no open browser windows on Mac
Assignee: mano → mconnor
Status: NEW → ASSIGNED

Updated

10 years ago
Blocks: 331908

Updated

10 years ago
Summary: Implement Camino style opening tabs replace as necessary functionality → improve open in tabs behaviour
Created attachment 274306 [details] [diff] [review]
v1

behaviours introduced with this patch:

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)
Shift+click on Open in Tabs opens the tabset in a new window
middle click on folder appends tabset (Same as Accel+click behaviour)
Attachment #274257 - Attachment is obsolete: true
Attachment #274306 - Flags: review?(mano)

Updated

10 years ago
Duplicate of this bug: 390115

Updated

10 years ago
Duplicate of this bug: 216346
Duplicate of this bug: 390393
Comment on attachment 274306 [details] [diff] [review]
v1

For middle-click on the open-in-tabs item, this relies on the menu view (menu.xml) considering the parent node as its selection when a "static" item is selected, since that is actually a bug (see bug 384968) we better use a separate code path for this case. For sanity you might want to move most of openLinksInTabs to PlacesUtils (and make it take the the node(s)).
Attachment #274306 - Flags: review?(mano) → review-
Created attachment 277494 [details] [diff] [review]
v2

hooks up context menus, moves openLinksInTabs out of the controller and refactors it a little.  Still relying on bug 384968 here, not sure how to fix that properly, but its easy to actually pass the right node from the oncommand (and remove the fallback code in openFolderInTabs) if someone can tell me how.
Attachment #274306 - Attachment is obsolete: true
Attachment #277494 - Flags: review?(mano)

Updated

10 years ago
Whiteboard: [need review Mano]
Created attachment 277997 [details] [diff] [review]
v2.1

address a comment from dietrich
Attachment #277494 - Attachment is obsolete: true
Attachment #277997 - Flags: review?(dietrich)
Attachment #277494 - Flags: review?(mano)
Comment on attachment 277997 [details] [diff] [review]
v2.1

still willing to review this.
Attachment #277997 - Flags: review?(dietrich) → review?(mano)
Created attachment 279276 [details] [diff] [review]
better

This also enables "Open All In Tabs" for saved-searches (i.e. queries) and host nodes (in the history sidebar).
Assignee: mconnor → mano
Attachment #277997 - Attachment is obsolete: true
Attachment #279276 - Flags: review?(mconnor)
Attachment #277997 - Flags: review?(mano)
Whiteboard: [need review Mano]
Comment on attachment 279276 [details] [diff] [review]
better


>+  _openTabset: function PU__openTabset(aURLs, aEvent) {
>+    var browserWindow = getTopWin();
>+    var where = aEvent && browserWindow ?
>+                whereToOpenLink(aEvent, false, true) :
>+                (browserWindow ? "current" : "window");

So, it took me some help from Mossop to parse this in my coffeeless state.  whereToOpenLink will already return current if !aEvent, so this seems overly complicated.  Should be able to just do:

var where = browserWindow ? 
            whereToOpenLink(aEvent, false, true) :
            "window";

other than that, r=me

Updated

10 years ago
Attachment #279276 - Flags: review?(mconnor) → review+
mozilla/browser/base/content/browser-places.js 1.48
mozilla/browser/components/places/content/controller.js 1.179
mozilla/browser/components/places/content/placesOverlay.xul 1.18
mozilla/browser/components/places/content/utils.js 1.62
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
Created attachment 279350 [details] [diff] [review]
as checked in
Attachment #279276 - Attachment is obsolete: true
Attachment #279350 - Attachment is patch: true
Attachment #279350 - Attachment mime type: application/octet-stream → text/plain
Blocks: 395024
verified with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007091005 Minefield/3.0a8pre
Status: RESOLVED → VERIFIED
Flags: in-litmus?
Blocks: 395082
heads up, this caused a regression:  open in tabs disabled for folders in the left hand pane of the organizer.  see bug #395082 for details (and the fix from dietrich)
(In reply to comment #29)
> Created an attachment (id=274306) [details]
> v1
> 
> behaviours introduced with this patch:
> 
> 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)

http://litmus.mozilla.org/show_test.cgi?id=4708

> Ctrl/Cmd+Shift+click on Open in Tabs appends the tabs and leaves selection
> alone (background load)

http://litmus.mozilla.org/show_test.cgi?id=4707

> Shift+click on Open in Tabs opens the tabset in a new window

http://litmus.mozilla.org/show_test.cgi?id=4706

> middle click on folder appends tabset (Same as Accel+click behaviour)

http://litmus.mozilla.org/show_test.cgi?id=4705

Let me know if those testcases have issues...
And now, for my latest trick, pasting in the URL for "click on Open in Tabs replaces the currently selected tab with the tabset"

http://litmus.mozilla.org/show_test.cgi?id=4709

Updated

10 years ago
Flags: in-litmus? → in-litmus+
Depends on: 399113
Depends on: 400491
Depends on: 403074

Updated

10 years ago
Duplicate of this bug: 404152

Comment 46

10 years ago
This may not TECHNICALLY be destructive behaviour, but if you have a few windows and a bunch of tabs going it's pretty easy to not notice that some of your tabs have been overwritten.

Also, yes you have the back button but since you usually want BOTH the new and old tab contents open that's not very helpful.

I think the question to ask is "What behaviour would the user expect from this functionality?".  IMO, most people would not be expecting it to overwrite their currently open pages.  I know I wouldn't.

It may be cluttered but cluttered trumps confusing and inconvenient any day, IMO.  They're not going to launch a folder's-worth of pages if they're not prepared to handle clutter.
Depends on: 424319

Comment 47

9 years ago
This IS broken.

I often have 30 to 50 tabs open while doing research and losing all that data because I clicked "Open All in tabs" for 3 bookmarks is totally unacceptable.

compare about 100 'closed as dupe' bug reports on https://bugzilla.mozilla.org/show_bug.cgi?id=216346

This BUG screams to be fixed right and deserves to be.

Some brainfarts:
1] "Open All in tabs" should warn "Open All in EXISTING tabs"
2] Add an option to "Open All in tabs in a new window"
3] Add alternate menu/bookmark choice to "Open All in NEW tabs"
4] Add an OOOOOPS button to undo the damage done.
5] the default for "browser.tabs.loadFolderAndReplace" should be FALSE
6] never close tabs in excess of the number of "All" bookmarks.  Opening 3 bookmarks with this command should not close 47 of 50 existing tabs.
7] if existing behavior is maintained, there should be added a pop-up warning to the effect that "All data in existing tabs will be replaced and tabs in excess of [xx] will be closed with all data being discarded/lost.  Are you sure you want to proceed?  [Y/N]

An Ooooops button, to revert/undo to previous state should be added regardless for unexpected or accidental activation of this destructive behavior.

Comment 48

9 years ago
BugMagent: This was fixed almost 7 months ago and has been in most of the beta releases and will be in the Firefox 3.0 release.  "Open All in tabs" will not replace currently opened tabs and will now open them in new tabs without overwriting anything.  For the time being, in the address bar, type about:config, search for 

Comment 49

9 years ago
Is there any way to turn this off in the firefox 3 release?
I actually preferred the old behavior, and don't know how to get it back!

Comment 50

9 years ago
Ben, Bugzilla is not the place for user support questions. Please use the channels available at support.mozilla.com.

Comment 51

9 years ago
As suggested, I used the support forum.
http://support.mozilla.com/tiki-view_forum_thread.php?forumId=1&comments_parentId=31629#threadId31650

It appears that there is no way to override the new tab behaviour.   I prefer the "replace all tabs" behaviour, and that does not seem to be an option.  Apparently the old setting browser.tabs.loadFolderAndReplace does not work any more, according to bugs 409122 and 395024.
I have entered a new bug 426127 to address this issue.

Comment 52

9 years ago
(In reply to comment #48)
> BugMagent: This was fixed almost 7 months ago and has been in most of the beta
> releases and will be in the Firefox 3.0 release.  "Open All in tabs" will not
> replace currently opened tabs and will now open them in new tabs without
> overwriting anything.  For the time being, in the address bar, type
> about:config, search for 

Actually, yes, "Open All in Tabs" WILL replace currently opened tabs.  Specifically, it will replace the contents of the tab you are currently focused on with the first bookmark in the folder and will then insert the remaining bookmarks as tabs to the right of selected tab.  So it preserves the existing tabs, except for the one you are focused on.  At least, this is what it does for me in Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b5) Gecko/2008032619 Firefox/3.0b5.  This is the new expected behaviour but it definitely does not represent a case of the "no current tabs being overwritten."

Also, Ctrl/Cmd+Shift+click does not work as advertised (for me, at least).  The results when I Cmd+Shift+click "Open All in Tabs" is identical to simply clicking "Open All in Tabs"

Middle-click on "Open All in Tabs" does work as described (appends the bookmarks in the folder as new tabs and selects the first new tab [foreground load]).

Shift+middle click on "Open All in Tabs" does not work as described.

This behaviour, from what I can tell, is a mess.  At the very least, there should be about:config options to duplicate the behaviour from FF2 that people were used to without requiring Ctrl/Cmd+Shift keypresses.  But instead browser.tabs.loadFolderAndReplace has been obsoleted.

At the very least, though, the Ctrl/Cmd(+Shift)+click options should work as described.  And they don't.

Comment 53

9 years ago
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.

Updated

9 years ago
Depends on: 431533

Comment 54

9 years ago
I couldn't agree more.

The issue is whether the computer should dictate to the user or vice versa.
All too often it appears that design decisions are not made from the users'
preference. Years ago there was a big discussion about whether tabs should 
be implemented in Mozilla with most of the developer comments arguing that
they were unnecessary, should not be part of the core code, and if anybody
really wanted them then go use an extension. Opera, then and now, seems to
be the only one getting it right.

Interface and functionality should be driven by user/customer preferences
and needs. However, there does not seem to be an easy, effective way for 
general user input to be communicated to the developers. This list is not 
something the average user can or is willing to access.

IMHO, this specific issue should be resolved according to what action one 
would normally expect from the command open all in tabs. If one selected a
single link to open in a tab one would be very surprised if the page opened
in the current window. By extension, one would expect similar behavior for
multiple links. I frequently have 20, 30, 40 tabs open when adding another
tabset and do not want to lose any that are already open. 

However, we're not all the same. As I understand it, that is what the key browser.tabs.loadFolderAndReplace is supposed to handle - so each of us can
have it our way - and should not be obsoleted. Control should belong to the
user.

Contrary to comment #48, I have set browser.tabs.loadFolderAndReplace to 
false and still get the active tab overwritten.

Comment 55

9 years ago
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.

Comment 56

9 years ago
In RC5 anyway Kurt Schultz in comment 48 is exactly right, whether you set   browser.tabs.loadFolderAndReplace to true or false, the tabs were NEVER overwritten as was the case in all prior versions of Firefox and the way I use Firefox. I don't care what you guys decide the default is, I just want an option that allows me to choose overwrite when I open a group of tabs. Otherwise Firefox 3 will be wholly useless to me and the way I use it. I'll have to go back to IE and I don't want to.

I have NOT yet tried the latest sneek peek beta release because it took me a half a day of work to uninstall the prior release candidate and get back to browsing in  v.2.  I'm waiting for some indication this option is working before I move on.

...Dale
I made an extension that makes the browser.tabs.loadFolderAndReplace pref useful again, see: http://martijn.martijn.googlepages.com/replacetabsreplacetabs.xpi
It seems to work just fine, but no guarantees.

Comment 58

9 years ago
Martijn.  Thank you!!! I've tried this on one of my machines and it seems to work.  I'll update my post:

http://www.daleisphere.com/work-around-for-firefox-3s-open-in-tabs-overwrite-bug/

to include it.  Let me know if you get this added into the official Mozilla Add-ons page and I'll update my post once again

Comment 59

9 years ago
FYI, I added a new post explaining how to use this new extension and formally thanking Martijn:

http://www.daleisphere.com/fix-for-firefox-3s-open-in-tabs-overwrite-bug/

...Dale

Updated

9 years ago
Duplicate of this bug: 427667

Comment 61

9 years ago
This is a real can of worms. Now we have 3 different versions of the "Open All in Tabs" functionality, but no builtin way to configure it the way you want.

Is there any plan to make "Open All in Tabs" consistent with the middle click? If so, it would be nice if all 3 versions were available.
Created attachment 384615 [details]
updated replacetabs extension

fyi, I've just updated the replacetabs extension, so it works in Firefox3.5 and trunk. I'm attaching it to this bug, for the people interested. It probably will take a while before it gets through AMO.

Comment 63

8 years ago
Terrific Marijn ... I was worried about this. So the old one doesn't work? We have to update? It's good to know there is an add-on out there we can turn to when we make the jump. 

...Dale

Comment 64

8 years ago
I just updated my blog post on the topic to include Maritjn's direct link:

http://www.daleisphere.com/fix-for-firefox-3s-open-in-tabs-overwrite-bug/

If/when it becomes available through the Firefox extensions page, I'd appreciate it if someone could post here and let us all know.

...Dale
(In reply to comment #63)
> Terrific Marijn ... I was worried about this. So the old one doesn't work? We
> have to update?

The old one only works for Firefox3.0.x. For Firefox3.5 (and trunk) you need to update. The new version should also work well in Firefox3.0.x, btw.

Comment 66

8 years ago
What is the deal with this in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.4pre) Gecko/20090903 SeaMonkey/2.0b2pre ID:20090903004335 ?

Will the extension work? What about the Tab Clicking Options extension? 

Thanks.
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

Comment 68

8 years ago
Martijn:

Any change ReplaceTabs extension will be updated to support 3.6 anytime soon. I cannot move without it.   There certainly are a lot of people who will want it including those requestiong the update here:

https://addons.mozilla.org/en-US/firefox/addon/8511

Please???
Created attachment 429550 [details]
replacetabs extension, Fx3.6 compatible

Sorry for the delay, here is the replacetabs extension, compatible with Fx3.6.

Comment 70

7 years ago
Thanks so much Martijn!
You need to log in before you can comment on or make changes to this bug.