bugzilla.mozilla.org has resumed normal operation. Attachments prior to 2014 will be unavailable for a few days. This is tracked in Bug 1475801.
Please report any other irregularities here.
Please report any other irregularities here.
Visual symptoms are exactly like those in bug 466311, but upon startup I don't see the same error message in the console. If I click around (e.g. on the blank folderpane area), I then see the following in the console: Error: this._treeElement is undefined Source File: chrome://messenger/content/folderPane.js Line: 216 I can see the list of accounts if I use the dropdown on the 'Get Mail' button. From the pushlog, I'm blaming bug 464808 as the likely candidate. (happy to email prefs.js to a developer if it would help)
this._treeElement is assigned incredibly early in the load, http://mxr.mozilla.org/comm-central/source/mail/base/content/folderPane.js#61 This suggests that there's a startup error before we even try to initialize the tree. If I had to guess, I imagine we're hitting a new error in loadStartFolder, that's being hidden by the bane of my existence: http://mxr.mozilla.org/comm-central/source/mail/base/content/msgMail3PaneWindow.js#1008 I'd recommend checking in a fix changing that dump() to a Components.utils.reportError() call for the purposes of the beta, so allow for better reporting. (Post beta Bug 467083 will clean things up more, but that's too risky to land now.)
Doug, you can mail me your prefs.js, thx.
(In reply to comment #2) > Doug, you can mail me your prefs.js, thx. Done (In reply to comment #2) > Doug, you can mail me your prefs.js, thx. Done. Just tried running with -console, and got the following which looks important: Search integration running in backoff mode error verifying accounts [Exception... "Component returned failure code: 0x80004 005 (NS_ERROR_FAILURE) [nsIMsgAccountManager.createLocalMailAccount]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: chrome://messenger/cont ent/accountUtils.js :: verifyAccounts :: line 173" data: no]
Doug, did you have a local folders account before? There's no account that points at the local folders directory, though there is a server that does. Just no account hooked up to that server.
actually, I take that back - server1/account1 is your local folders account. But the local folders server pref is set to server2...
So, the problem is that you had two local folders accounts. We removed the second one we saw, but the localfoldersserver pref was set to that one, so now we think there's no local folder server, and we can't create one because we think there already is one (I think). You also have two local folder directories in your profile (Local Folders and Local Folders-1). I'm not sure which one was actually getting used before; it would be helpful if you could look at the contents of those two directories and say which one has the right stuff...depending on which one is the right one, I could either fix this by preferring the one specified by the localfoldersserver pref, or by setting the localfoldersserver pref to the first one. I'm not sure which one rdf would have shown you in the folder pane. Doug, you can probably fix your problem by changing the pref user_pref("mail.accountmanager.localfoldersserver", "server2"); to server1. But I'm not sure if you'll be seeing the right local folders or not. If not, the right fix would be to change user_pref("mail.account.account1.server", "server1"); to server2.
Created attachment 350694 [details] [diff] [review] [checked in] possible fix I think this is the right thing to do, but I need some feedback from Doug. I believe that the code would have been showing Doug the Local Folders directory, even though the localfoldersserver pref was set to the server for the Local Folders-1 directory.
(In reply to comment #7) > Created an attachment (id=350694) [details] > possible fix > > I think this is the right thing to do, but I need some feedback from Doug. I > believe that the code would have been showing Doug the Local Folders directory, > even though the localfoldersserver pref was set to the server for the Local > Folders-1 directory. I don't have a Local Folders-1, so that bit is completely wrong! Manually changing localfoldersserver to server1 has fixed the issue - today's nightly loaded fine after doing that. My profile has been around since Thunderbird 0.3, so it's probably one of the oldest out there...
Thx, Doug, that implies that this fix would do the right thing for you... Standard8, is there a way to do unit tests given a prefs.js file as a starting point? Or can you write code to manually set prefs in the unit test to define accounts and servers, and then cause the accounts to get loaded?
putting on b1 list - my suspicion is that there will be enough people with this issue that it will be easier to fix it than explain to each of them how to correct their prefs.
Flags: blocking-thunderbird3? → blocking-thunderbird3+
Target Milestone: --- → Thunderbird 3.0b1
Comment on attachment 350694 [details] [diff] [review] [checked in] possible fix Yep, lets give this a try. I'll check it in so that it gets into the nightly. Re unit tests. There's two ways you may be able to do this. First you could try copying a prefs.js to the profile directory before doing any mailnews stuff (the address book tests do_copy_file for .mabs before they test). If that doesn't work, then you could poke them in via nsIPrefBranch and then load the accounts etc.
Comment on attachment 350694 [details] [diff] [review] [checked in] possible fix Checked in: http://hg.mozilla.org/comm-central/rev/8fcff769ca76
Attachment #350694 - Attachment description: possible fix → [checked in] possible fix
This will be in today's nightlies (20081201) if anyone can test as soon as they come out that would be very useful.
Whiteboard: [possible fix checked in]
I'm going to mark this fixed...we'll re-open if we hear of any more issues like this.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
This FIXED bug is flagged with in‑testsuite? It would be great if assignee or someone else can clear the flag if a test is not appropriate. And if appropriate, create a test and plus the flag to finish off the bug.
You need to log in before you can comment on or make changes to this bug.