Closed Bug 379828 Opened 17 years ago Closed 15 years ago

Freeze and high CPU Utilization when loading HTML messages

Categories

(MailNews Core :: Backend, defect, P2)

Product:
MailNews Core
Component:
Backend
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
Thunderbird 3.0a3

People

(Reporter: lholling, Assigned: standard8)

References

Details

(Keywords: perf, regression, testcase)

Attachments

(3 files, 1 obsolete file)

Typical html email that cases this bug to appear (in mbox format)
89.99 KB, text/plain
Details
The fix (checked in)
4.69 KB, patch
neil
: review+
Bienvenu
: superreview+
Details | Diff | Splinter Review
Branch patch
3.85 KB, patch
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3
Build Identifier: 2.0

Since upgrading from 1.5 any HTML mail now cause the computer to jump to high utilization and the message takes a long time to load. With 1.5 the message was displayed and you could read it quite easily.

It seems to be with most HTML mail. The short term solution is to change the "View As" settings to simple HTML but you lose too much of the formatting of the message

Reproducible: Always

Steps to Reproduce:
1. Receive HTML Mail in Original HTML mode
2. Try to view the email
3.


Expected Results:  
Should load the message in the same sort of timeframe at 1.5
Version: unspecified → 2.0
Absolutely same problem here. I use Thuderbird 2.0.0.0 on Windows XP + SP2 and viewing HTML mail is very very slow with high CPU utilization.

"View As" settings to "simple HTML" did not help.
Leonard, Pajlo,

how big is the message?
what happens if you turn off (uncheck) phishing detection? 
  tools > options > privacy > e-mail scams 

I mailed my firefox bookmarks, 8meg message, now in a local folder.
click on message with phishing enabled locks all thunderbird UI for 5 minutes with high cpu.
without phishing on UI frees in less than 5 seconds
I've determined the thunderbird UI is not totally locked out during the entire phishing detection process.  I was able to occasionally click some other areas at times.  And also managed to cause Bug 387506.  

One item is locked out while the message is "loading", at least as far as I could tell, is any already open advanced search, window, the window goes and stays blank until the main window frees up.
The last message that I tried was a HTML one that was about 30K in size. All things on TB stop until it has completed whatever it is doing. Once the message is loaded then TB behaves fine and CPU utilisation returns to normal.
please quantify, how much time?
and with phishing off?
can you provide a sample message?
Let me get a message that has the problem and I will forward it to you. It has been a while because I went back to TB 1.5
It can take 10-15s to display a HTML message, even if phishing is off (I even restarted Thunderbird) and images not displayed to protect privacy .

I also noticed that there is a message like "unknown "word-break" property..." in the error console. But I am not sure it is related to our problem.

I will forward you a message. I hope it will not be considered as spam...
same to me, about 10 second to display HTML files on OSX.

Here you can find an EML zipped email...very slowing reading on macosx

www.c4dzone.it/clienti/mozilla/test.zip
Mmh I cannot reproduce it with mentioned testcase from comment 8. Has anyone a working MBOX which he could attach to this bug? It should only contain that single message.

Further please create a fresh profile and test it there. Does it also happen?
I created a fresh profile and transfered the mailbox. There was no problem any longer. The message was quickly displayed. There must be something in the previous profile which causes the problem... Note that it was a profile created with 1.5 version of Thunderbird.
Interesting. One thing I forgot. Could you also try to start in Safe Mode? An extension could also raise such a problem. A fresh profile won't have any extension. So if you have installed some of them in your not working profile they could be the issue.
I tried the safe mode but it didn't change anything. I will try to check out the preferences.
I tried to copy the preferences in the new profile but the problem was always there. So I decided to look for other differences. I tried to clean my address books and delete all the ones that I didn't need and... the problem disappeared. To identify the problem, I tried to restart from the previous version of the profile and made my tests in safe mode. I deleted one address book. This time the result was more surprising: if you keep the address book window opened, the HTML message is displayed quickly. If you close the address book window, it is displayed very slowly. I tried to delete other address books but actually the behavior remained the same. Even if I thought having reached the same state like the profile where the problem fully disappeared. Strange... So it seems this problem could be related to the address book. Or at least, opening the address book seems to influence it. Maybe it will give you some clue.
I made a small mistake in my last comment: when I copied the preferences in the new profile, the problem was no longer there.
I concur with the Address book findings. If the address book is open then it works for viewing the messages as expected. 

I deleted all of the entries from the Collected Addresses address book (and restarted TB 2.0) and it did not fix the problem. I also tried turning off the Local Address book lookup and the problem was not fixed. 

The temp fix is to leave the address book open and it all works...

ok but the mistake is that was not happen to me on TB 2.0 on WinXp really now, but happen to me on a Quad Intel Apple with TB 2.0.
Are you using OSX? or winXP? because I noticed diferences..

Alex
I am using Vista. But I think I had the problem on Windows XP too.
argh...I hope for a solutions, I'm using TB 1.5 on osX....grrrr
I have the problem with Windows XP SP2 latest patches. As mentioned previously keeping the Address Book open solves the problem now if only we knew the cause...

mmm...I like wait untill the problem will be solved :)
Could someone who can see this issue prepare a new profile with a dummy account and the affected message? I think this would be the more efficient way. You could send it to me directly. Currently I cannot reproduce it on WinXP and OS X.

Otherwise do you have multiple address books? Does it also happen if you remove all entries from each of the address books?
Agree about address book being open. Messages display instantly when address book open and take 20-30 seconds when address book closed! Using XP Media Centre with all patches. TB process goes to 100% and stays there as message displays VERY VERY slowly. Seems to be only with HTML messages, plain text displays instantly regardless of address book status.
 
By the way, this bug is mentioned MANY MANY times in the bug list under different key words!! I counted at least 10 separate bug reports for this single bug.
Add a comment for the coders! If you open the address book while the message is "Loading" then it loads instantly as soon as the address book is open. 

Also works if the address book is minimized.
(In reply to comment #22)
> By the way, this bug is mentioned MANY MANY times in the bug list under
> different key words!! I counted at least 10 separate bug reports for this
> single bug.

In a quick search I see only a few are 2.0 specific and aren't linked to other causes.
bug 370541
bug 380713
bug 369345

Jon, it will a great help if you can cite the other bugs that are 2.0 specific and match symptoms.
Phil, Magnus what do you make of comment 23?
I have just upgraded to Tbird 2.0 from 1.5.x on Mac OS 10.3.9, and can confirm that keeping the Address Book open "magically" resolves the slowness of both opening (even before manually loading images) and deleting messages. And it works every time.

Doesn't make sense to me how the Address Book is related to the problem (and maybe it's not directly related aside from resolving it), but there's obviously a real major bug here.

Any prognosis for fixing this?

Thanks,
Fred
Fred, can you make a copy of your existing profile and run a trunk nightly build? It would be interesting to know if it's still an issue for Thunderbird 3.

ftp://ftp.mozilla.org/pub/thunderbird/nightly/latest-trunk
(In reply to comment #27)
> Fred, can you make a copy of your existing profile and run a trunk nightly
> build? It would be interesting to know if it's still an issue for Thunderbird
> 3.
> 
> ftp://ftp.mozilla.org/pub/thunderbird/nightly/latest-trunk

Hi Henrik,

Thanks for your suggestion, but I have no idea how to do what you're asking; I'm in over my head here.

Fred

Fred, I'm sorry. So just some questions. How old is your profile? I believe it's the same which you used with Thunderbird 1.5? Perhaps this is a migration issue. Can you first create a new profile with the help of the profile manager? Therefor please have a look at http://kb.mozillazine.org/Profile_Manager. Create a new account and retrieve such a HTML message afterwards. Does the issue exists even now? It's a bit strange because I'm not able to see it with Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.8pre) Gecko/20070927 Thunderbird/2.0.0.7pre ID:2007092705.
I just did that what you asked Fred to do - run current trunk nightly with a copy of my existing profile (that exhibits the HTML message "slowdown"). The problem is still there, what's funny it seems (subjective only, I did not measure it) to be even worse, by about factor of 2. Opening the address book also cures the symptoms completely. 
BTW - my profile is old, from TB 1.5 at least, and quite big (5.5 GB, mails from last ~ 7-8 yrs, part of this imported from other MUA's). It therefore might a be a migration issue (weird, nonetheless...). Question - anyone subscribed to this bug (and having problems with HTML messages etc.) has a "fresh" profile, created in TB 2.0?  
I started experimenting with the profile contents and noticed that purging (deleting all addresses) from the address book seems to solve the problem. Fred - could you test it? Unfortunately after importing the addresses back (I have around 3000 entries in AB) the issue reappears :( Something weird is going here...
Henrik, my profile does predate 2.0.

I know it would be helpful to those trying to solve this problem, but I admit to an aversion to creating a new profile, largely because of warnings like this: "Care must be taken when creating and deleting profiles to avoid loss of valuable data." I tend to err on the side of "First, do no harm."
First off apologies if I'm putting these comments in the wrong place. If so could somebody shift them to a more appropriate thread for me, thanks.

I'm using Thunderbird 2.0.0.6 on Windows XP SP2, 2.4GHz Pentium and 1GB RAM.

I ended up here looking for a reason my email address completion was so slow. Picking up on a few remarks I thought I'd see if my address book could be cleaned up. I exported it as LDIF, moved abook.mab out of the way (closing Thunderbird whilst I did this), then imported back in. Didn't help :-)

Next tried opening address book. Presto, with the address book open address completion is almost instant (except for first address, see remarks below) and there is no delay after selecting an address from the list offered.

Close the book and the delay is back. Type a few characters then have to wait 15+ seconds for candidates list. Select an address and there's another delay of about the same length, or longer.

Now then. Open the address book and there's a delay of about 7 seconds before it displays. Click 'Write', first address big delay again, subsequent addresses almost instant.

Dump the message, click 'Write' again. All addresses, including first, almost instant.

Dump the message, close the address book, click 'Write' again. The delays are back, both before and after selecting an address.

I've not tried downloading new mail with the address book open yet. Need to wait for some to arrive :-)

I'd mention that it's not just the mail composition window that's blocked. The whole program seems to go modal during the delay, like everything's running single threaded and blocked on I/O.

If I had to make a guess I'd say that during address look up something is being loaded (and parsed?) in memory then unloaded after address selection. Presumably with the address book open this gets loaded but stays loaded, or is cached.

I'd ask if there is some sort of address parsing going on as new messages are downloaded (even though I have store saved addresses turned off)?

By the way I haven't tried creating a fresh profile. Echoing the remark by Fred I'd ask what's the quickest and easiest way to get everything from my current profile into a new profile without having to re-enter all my addresses, preferences, and mail?
Forgot to mention the profile is an import from Netscape 7.
Is this the runaway address book prefs problem? If you go into tools | options | advanced, general, config editor, and type ldap_2.servers, do you get a lot of hits for servers with -NN names, e.g., server01, server02, etc?
Get a lot of matches with that filter but not server01, server02, etc.. Do you know the bug number and I'll give it a read. Thanks.
I got the pref name wrong - it's ldap_2.servers.user_directory_NN, according to bug 230580
I did have 8 'ldap_2.servers.user_directory_NN' entries wich I deleted from prefs.js but it made no difference to the behaviour.
I confirm this problem with Iceape 1.1.5 under Linux. Open address book also solves the troubles.

Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.8) Gecko/20071008 Iceape/1.1.5 (Debian-1.1.5-1)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: perf
OS: Windows XP → All
Leonard, Max, do you see the problem _only_ with phishing turned on? (see comment 2) i.e. what happens if it's turned off?

(others who see it with phishing turned off may be seeing a different problem given for some it happens only when phishing is turned on)
Keywords: regression
Wayne, why this should be a regression? I don't think that we have identified it as such one atm.
not definitively, no.

however, STM comment 26 and comment 0 "Should load the message in the same sort of timeframe at 1.5" point in that direction 
Than it would be great to have a good testcase. There is still none available. 

Max, please run tests with original builds from Mozilla. Does this happen for each HTML file? If not can you attach the affected one. Also try to get this reproduced with a fresh profile without any addons and default settings.
I've tested this bug with Seamonkey 1.1.4 release (I cannot test newer ones as they are not yet available for x86-64), the symptoms are the same.

Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.6) Gecko/20070803 SeaMonkey/1.1.4

I cannot find phishing control in Seamonkey, there seems to be only Junk mail control.

I am attaching a particular html email (in mbox format) that is affected by this bug.




(In reply to comment #43)
> I cannot find phishing control in Seamonkey, there seems to be only Junk mail
> control.

I don't see it either.  In about:config (in the URL bar) plug in
  mail.phishing.detection.enabled  
True(default)=enabled
double click or right click to change

Turning phishing detection ON/OFF does not change anything. So, phishing detection is irrelevant to this bug.
Max, please create a fresh profile and use your testcase to run a test there. I'm even not able to see the issue on OS X.
Er, I have to revert. This testcase is perfect. I'm able to reproduce it with my daily profile and Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.10pre) Gecko/20071108 Thunderbird/2.0.0.10pre ID:2007110808
Keywords: testcase
Also on trunk with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b2pre) Gecko/2007110817 Thunderbird/3.0a1pre ID:2007110817
Version: 2.0 → Trunk
Ok, we are a bit closer now. It depends on the amount of contacts you have in your address books. If only a few people are added you won't be able to see this bug.

While testing I noticed that also after deleting all addresses from within an address book the addresses still remain in the appropriate .mab file. Shouldn't they completely removed? That's why the count of my collected addresses were nearly 400 which slows down the display of attachment 287911 [details]. After removing the file manually all works fine.

It's strange why that works while the address book window is open.

Mark, do you have an idea?
Assignee: mscott → nobody
Component: General → MailNews: Address Book
Product: Thunderbird → Core
QA Contact: general → addressbook
(In reply to comment #50)
> Mark, do you have an idea?

I think I do. From what I've read on this bug:

1) Loading is fine when phishing (scam detection) turned off.
2) Loading is fine when phishing on & address book open.
3) Loading appears fine when fewer contacts in address book (or no file?).

Is this correct?

If you have an email with lots of links in it (no remote content) is that slow?
If you have an email with lots of remote images in it (no links) is that slow?

Like I say I think I've got an idea. Something to do with how the content loading policy is working. Henrik, if you're able to answer my questions, I can try and have a focused look at the problem.
(In reply to comment #51)
> 1) Loading is fine when phishing (scam detection) turned off.

No, whatever if it's enabled or disabled it's slow.

> 2) Loading is fine when phishing on & address book open.

Leave phishing alone. Just the address book has to be open.

> 3) Loading appears fine when fewer contacts in address book (or no file?).

Right. But even you have deleted all contact within an address book they still appear inside the .mab (file as new bug?) and make it possible to see this bug. 

4) You should have turned on 'Original HTML' to see this. Other views don't show this behavior.

> If you have an email with lots of links in it (no remote content) is that slow?

After modifying all external links to point at file:// it's really fast, yes.

> If you have an email with lots of remote images in it (no links) is that slow?

Yeah. I changed all remote links to local links before. The perf is just as bad as before.

> Like I say I think I've got an idea. Something to do with how the content
> loading policy is working. Henrik, if you're able to answer my questions, I can
> try and have a focused look at the problem.

You can still reproduce this issue on your own by creating a new profile, putting around 300 contacts in your address book and opening the attached testcase. Otherwise you can just ask me again.
(In reply to comment #52)

Thanks for the additional info.

> > 3) Loading appears fine when fewer contacts in address book (or no file?).
> Right. But even you have deleted all contact within an address book they still
> appear inside the .mab (file as new bug?) and make it possible to see this bug.

see bug 65086.
Component: MailNews: Address Book → MailNews: Composition
QA Contact: addressbook → composition
Opps, sorry that should have been mailnews:backend. This problem is more a problem with MsgContentPolicy and not address book.
Component: MailNews: Composition → MailNews: Backend
QA Contact: composition → backend
Attached patch Possible Fix (obsolete) — — Splinter Review 
This is a potential fix.

The main point item is to cache the top-level address book. The other changes are more smaller changes that'll help speed up message display in other instances.

I would like to cache at the ab card level (and hence msg hdr address), but then I'm not sure we could be certain that the user hadn't changed the remote loading of images option between loading different emails with the same header address.

Neil/Scott/David: thoughts welcome, I've still got some things to test on this before I know how good it really is.
so this in effect saves us from re-opening the ab db all the time? If that's the case, that's going to be a much bigger win than caching lower level things like cards.
is this cross address book? Or is it limited to Personal AB?
Mark, your patch works very well. No cpu consumption visible over a longer period. The message is displayed immediately. Can you take the bug?
(In reply to comment #56)
> so this in effect saves us from re-opening the ab db all the time? If that's
> the case, that's going to be a much bigger win than caching lower level things
> like cards.

I think its actually caching the address book datasource/top level (nsAbBSDirectory) which is causing us to not to have to load them in each time. Still might be slow with lots of cards in the address book.

I'll try and stick some debug in in the next day or two and see if it means we don't reopen the ab dbs each time as well.
It's an enormous boost, Mark! Without your patch and approx. 1200 cards inside the address book it takes 30 seconds to finish loading. After your patch applied you have to wait less a second! 
This isn't limited to just TB... I've been testing & fixing in SM as well, so changing the title.
Summary: Thunderbird almost freezes and CPU Utilization goe high when loading HTML messages → SeaMonkey/Thunderbird almost freezes and CPU Utilization goe high when loading HTML messages
Same as the possible fix, but without the printf.

I've had a quick look, and keeping the rdf root (sudo) address book alive, keeps the rest of the address books alive in the list - we're not re-initialising them all the time.

Just after we've got the root rdf node, we call GetChildNodes, if the instance of the root rdf node hasn't been kept alive, this initialisation takes place for each and every remote image link that we load: http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/mailnews/addrbook/src/nsAbBSDirectory.cpp&rev=1.40&mark=134-186#132

This calls CreateDirectoriesFromFactory, and obviously re-initialising the directories all the time isn't a good idea.

So, there will be some memory impact (i.e. once loaded we probably won't be releasing the address book details till shutdown), but because the root node (nsAbBSDirectory) does actually manage things I expect there to be no problem with adding new address books/removing old ones, and I've checked this works as well.

This may actually help to speed up other areas of sm/tb that access the address books as well.

This is a patch for trunk. I need to get & build branch before I'll submit a patch for that.
Assignee: nobody → bugzilla
Attachment #288004 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #288050 - Flags: superreview?(bienvenu)
Attachment #288050 - Flags: review?(neil)
(In reply to comment #46)
> Turning phishing detection ON/OFF does not change anything. So, phishing
> detection is irrelevant to this bug.

revisiting this point with the perf issue resolved

- if html email caused the perf problem, then how is it that phishing is not involved?  Or ...
- if phishing is involved, then why did turning off phising not kill the perf symptom?
(In reply to comment #63)
> - if html email caused the perf problem, then how is it that phishing is not
> involved?

Phishing detection is involved when you're checking an html email, but its impact on perf is minimal compared to the current impact that we're getting from having to re-initialise the address book structure every time we find a link.
Blocks: 403256
Summary: SeaMonkey/Thunderbird almost freezes and CPU Utilization goe high when loading HTML messages → Freeze and high CPU Utilization when loading HTML messages
Attachment #288050 - Flags: review?(neil) → review+
Attached patch Branch patch — — Splinter Review 
Patch for branch. This works the same as the trunk patch, just allows it to be applied to the branch.

I'll wait to get the trunk patch reviewed & committed before I progress this one.
I've verified that this keeps all the local address book databases loaded in memory for the lifetime of Thunderbird, and keeps the files open on disk. This is the classic trade-off of memory usage vs. performance. I'm not crazy about keeping all the ab's open and in memory forever, but it's far better than re-opening them every time you read an html message with links.
Attachment #288050 - Flags: superreview?(bienvenu) → superreview+
David, which extra memory usage we can expect? Are these some KB or several MB? I know it depends on the amount of cards added but just an inexactly value?
very very roughly around the size of your local .mab files
David, does that also include address cards which are already deleted but not removed from the .mab file? I think yes or am I wrong?

When it will be checked in so we can run tests with official builds?
For the most part, no, it doesn't.
Maybe this isn't new info, but just in case anyone was wondering, bug is still present in Thunderbird 2.0.0.9.

And keeping address book open still alleviates problem.
Fred, it's not fixed for Thunderbird 2 at this time. Have an eye on the keyword field on top. If fixed1.8.1.10 or a higher last number is entered it will be fixed for the corresponding Thunderbird 2.0.0.x version. But before that happens it has to bake a little on trunk. Mark, do we need approval1.9 to get it checked into the trunk?
Comment on attachment 288050 [details] [diff] [review]
The fix (checked in)

I have now landed this on trunk (Thunderbird 3.x and SeaMonkey 2.x builds) so that we can get some testing on it.

I still want to do some investigations of my own (e.g. memory usage like David commented) before I'll be happy for this to go onto branch.
Attachment #288050 - Attachment description: The fix → The fix (checked in)
(In reply to comment #66)

Simple questions:

> I've verified that this keeps all the local address book databases loaded in
> memory for the lifetime of Thunderbird, and keeps the files open on disk. This

Could this cause a data loss/corruption if the application does not exit properly, as when it crashes ?

> is the classic trade-off of memory usage vs. performance. I'm not crazy about
> keeping all the ab's open and in memory forever, but it's far better than
> re-opening them every time you read an html message with links.

Could the individual address books get a timeout/reload mechanism ?
Mark, did you had time run your tests? I would be interested in.
Assignee: bugzilla → nobody
Status: ASSIGNED → NEW
Assignee: nobody → bugzilla
Status: NEW → ASSIGNED
perhaps dupes
bug 392920
bug 378345

(In reply to comment #79)
> perhaps dupes
> bug 392920
> bug 378345

First one looks like a candidate. But second one is while fetching new messages. So it should be another issue. 


Just to note that the bug is still present in Thunderbird 2.0.0.14 running on Mac 10.3.9.

And keeping the TB address book open still rectifies the problem.

Fred
Mark, whats the current status of this bug? It seems that it was getting lost.
Here is ZIP file of my test mail box with aprox. 6 messages that are extremly slow.

If I export single message in EML file an then re-open it, it is blazing fast.
Address Book has no effect on the speed!

http://home.pia.si/users/luigi/Thunderbird_3.x_MBOX_WITH_SLOWWW_MESSAGES.zip
(In reply to comment #83)
> Here is ZIP file of my test mail box with aprox. 6 messages that are extremly
> slow.
> 
> If I export single message in EML file an then re-open it, it is blazing fast.
> Address Book has no effect on the speed!
> 
> http://home.pia.si/users/luigi/Thunderbird_3.x_MBOX_WITH_SLOWWW_MESSAGES.zip
> 
Ales, are you using the Thunderbird 3 alpha/nightly versions or Thunderbird 2? If you are using Thunderbird 3 it is unlikely to be this bug.

I am using Thunderbird 3 aplha.
version 3.0a2pre (2008052003).

It is possible that bugs are not related. But the same problem existed in T 2.xx.

Should I file a new bug?
Priority: -- → P2
Mark, can we mark this bug as fixed or do we need some special tests? If yes, how can I help?

(In reply to comment #85)
> I am using Thunderbird 3 aplha.
> version 3.0a2pre (2008052003).
> 
> It is possible that bugs are not related. But the same problem existed in T
> 2.xx.
> 
> Should I file a new bug?

If you cannot reproduce it with your Thunderbird 3 nightly build it should be the same bug. The fix hasn't landed on 1.8 branch yet. So Thunderbird 2 is still affected.
Flags: blocking-thunderbird3?
Hardware: PC → All
Product: Core → MailNews Core
Mark, bug 403256 (Make nsIAddressBook a service and keep the root rdf address book alive) is fixed now. What is the remaining work for this bug?
Comment #73 says this landed. Standard8: anything more to do here?
Flags: blocking-thunderbird3? → blocking-thunderbird3-
Whiteboard: [fixed?]
I'm not up on the lingo here, so I don't know what "landed" means.

But do I understand correctly that the fix for this bug won't happen until TB v3?

Using TB version 2.0.0.17 (20080914) on a Mac G4 733mhz, 10.3.9 and bug is still present, and keeping the TB address book open still rectifies the problem.
(In reply to comment #89)
> Using TB version 2.0.0.17 (20080914) on a Mac G4 733mhz, 10.3.9 and bug is
> still present, and keeping the TB address book open still rectifies the
> problem.

Indeed. There was no check-in for Thunderbird 2.0.0.x yet. Before that happens we have to verify the fix on trunk (which means the upcoming version 3).
As this will not be fixed until 3 is released (when is that slated???) perhaps someone can add an option in the settings or do an add on to auto open address book when TB opens in the 2 stream?
Whiteboard: [fixed?] → [fixed?][needs status update standard8]
Apologies for not doing a status update on this earlier.

This is fixed for the Thunderbird 3 builds - it was fixed before Thunderbird 3 Alpha 1. Therefore marking the bug as fixed as per standard practice.

For Thunderbird 2.x builds:

- The standard practice is that 2.x releases are for stability and security fixes only. Any patch needs to be justified to release drivers and may be rejected.
- Whilst this has shown to be stable on TB 3 builds, I'd be slightly concerned about it running on TB 2.x as I don't know that code as well, as it is now an old version.
- For accepting it, there would need to be a good summary of the cost/benefit tradeoffs as well as an idea of how badly this affects TB users (is it just some, or lots).
- I'd also want to see some checking that it is safe to cache the address book on 2.x build without causing adverse problems.

At the moment, I am deeply focussed on pushing 3.x as fast and as hard as I can, and I am not willing to try and move this on for branch. If someone else wants to, that is fine by me, but it may still be rejected by release drivers as mentioned above.
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Whiteboard: [fixed?][needs status update standard8]
Target Milestone: --- → Thunderbird 3.0a3
(In reply to comment #91)
> As this will not be fixed until 3 is released (when is that slated???) perhaps
> someone can add an option in the settings or do an add on to auto open address
> book when TB opens in the 2 stream?

there is a "Contacts Sidebar" Plugin, solves the Problem for me :-)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: