175124 - improve open in tabs behaviour

Status: VERIFIED FIXED

(Firefox :: Bookmarks & History, enhancement, P2)

Description

[Anoop Ranganath]

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

[André Dahlqvist]

Seams like a valid request for enhancement. Marking as enhancement and setting
as NEW.

Comment 2

[alanjstr]

Tabbed Browsing Extension seems to offer this.

Comment 3

[Anoop Ranganath]

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?

Comment 4

[Jesse Ruderman]

See also bug 208278, same or similar bug for Seamonkey.

Comment 5

[Alois Reisinger]

please see also #195212
,thx

Comment 6

[Robert Parenton]

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.

Comment 7

[Ben Goodger (use ben at mozilla dot org for email)]

-> 0.9

Comment 8

[Oakwine]

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

[Jon Henry]

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

[Neil Jenkins]

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

[Alan Arndt]

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

[u4664]

(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.)

Comment 13

[Jean-Marc M.]

(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

[Asa Dotzler [:asa]]

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

[Dan Allen]

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

Comment 16

[Jean-Marc M.]

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

Comment 17

[Mike Connor [:mconnor]]

Beltzner and I discussed this at length a couple weeks ago, I'll try to get that discussion written down and in this bug.

Comment 18

[Bradley Chapman (not reading bugmail, still gone but not forever)]

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.

Comment 19

[Mike Beltzner [:beltzner, not reading bugmail]]

(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. ;)

Comment 20

[John Mellor (Jomel)]

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

[Stian Soiland]

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

[u88484]

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?

Comment 24

[Majken Connor [:Kensie]]

mconnor - remembered the plan yet?

Comment 25

[Mike Beltzner [:beltzner, not reading bugmail]]

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.

Comment 26

[Mike Connor [:mconnor]]

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.

Comment 27

[Worcester12345]

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/

Comment 28

[Mike Connor [:mconnor]]

Attachment: 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

Comment 29

[Mike Connor [:mconnor]]

Attachment: 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)

Comment 33

[Asaf Romano (gone)]

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

Comment 34

[Mike Connor [:mconnor]]

Attachment: 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.

Comment 35

[Mike Connor [:mconnor]]

Attachment: v2.1

address a comment from dietrich

Comment 36

[Asaf Romano (gone)]

Comment on attachment 277997 [details] [diff] [review]
v2.1

still willing to review this.

Comment 37

[Asaf Romano (gone)]

Attachment: better

This also enables "Open All In Tabs" for saved-searches (i.e. queries) and host nodes (in the history sidebar).

Comment 38

[Mike Connor [:mconnor]]

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

Comment 39

[Asaf Romano (gone)]

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

Comment 40

[Asaf Romano (gone)]

Attachment: as checked in

Comment 41

[Tracy Walker [:tracy]]

verified with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007091005 Minefield/3.0a8pre

Comment 42

[(not reading, please use [e-mail] instead)]

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)

Comment 43

[Stephen Donner [:stephend] Not actively reading bugmail]

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

Comment 44

[Stephen Donner [:stephend] Not actively reading bugmail]

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

Comment 46

[Keith Bissett]

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.

Comment 47

[BugMagnet]

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

[u88484]

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

[Ben McKenzie]

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

[Asa Dotzler [:asa]]

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

Comment 51

[Ben McKenzie]

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

[Joey Connick]

(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

[sawickig]

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.

Comment 54

[Art K]

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

[Quintum]

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

[Dale Dietrich]

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

Comment 57

[Martijn Wargers (dead)]

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

[Dale Dietrich]

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

[Dale Dietrich]

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

Comment 61

[DavidE]

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.

Comment 62

[Martijn Wargers (dead)]

Attachment: 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

[Dale Dietrich]

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

[Dale Dietrich]

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

Comment 65

[Martijn Wargers (dead)]

(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

[Worcester12345]

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.

Comment 67

[Gervase Markham [:gerv]]

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

Comment 68

[Dale Dietrich]

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???

Comment 69

[Martijn Wargers (dead)]

Attachment: replacetabs extension, Fx3.6 compatible

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

Comment 70

[Dale Dietrich]

Thanks so much Martijn!