Closed Bug 880464 Opened 10 years ago Closed 10 years ago

Setting up an RSS account first should not make it the default account


(MailNews Core :: Account Manager, defect)

Not set


(thunderbird23 wontfix, thunderbird24 fixed, thunderbird25 fixed, seamonkey2.20 fixed, seamonkey2.21 fixed, seamonkey2.22 fixed)

Thunderbird 25.0
Tracking Status
thunderbird23 --- wontfix
thunderbird24 --- fixed
thunderbird25 --- fixed
seamonkey2.20 --- fixed
seamonkey2.21 --- fixed
seamonkey2.22 --- fixed


(Reporter:, Assigned:


(Blocks 2 open bugs)



(2 files, 1 obsolete file)

(Quoting rsx11m from bug 437139 comment #21)
> So, I've looked further into the default-account issue and found that the
> tests have to be a bit more extensive than just checking if it exists. As it
> turns out, also non-mail accounts (like the RSS account) may end up being
> set as the default account. I've managed to do this by cancelling the
> initial account setup first, then creating the RSS account, and only after
> that creating the e-mail account.

This works for news accounts (in which case Local Folders becomes the default account) but not for the feeds account. Neither a news or a feeds account should be permitted to be defined as the default account; only imap, pop3, or movemail.

Steps to reproduce:

 1. Start with a new profile
 2. Set up an RSS (Blogs & News Feeds) account
 3. Check its account key (should be "account2")
 4. See that mail.accountmanager.defaultaccount = account2 (feeds acct.)
 5. Also, mail.server.server2.{download_on_biff,login_at_startup} = true


 4. Should be mail.accountmanager.defaultaccount = account1 (local)
 5. prefs shouldn't be set as they are not applicable for RSS accounts
Attached patch Proposed fix (obsolete) — Splinter Review
The problem is that EnableCheckMailAtStartUpIfNeeded() is called in FinishAccount() based on serverIsNntp() as an explicit check whether or not it is a news server, thus also being triggered for RSS accounts.

I'm changing this to a check for the canBeDefaultServer attribute of the incoming server instead, which should be true for mail accounts (i.e., imap, pop3, and movemail) but not for any other account type (specifically not nntp or rss).

Tested with all five account types in varying order.
Attachment #759438 - Flags: review?(iann_bugzilla)
Attachment #759438 - Flags: review?(bwinton)
Local Folders also is not a good account to be set as default.

See also bug 342632 and bug 875675. Fixing bug 342632 is a long term problem.

But if you want I think I can make it like this:
1. if only Local Account exists, it is reported as default.
2. if a rss/news account is created, still Local Accounts is the default (the first account)
3. if a pop3/imap4 account is created now TB will automatically switch to it as the default account.
4. if any new pop3/imap4 accounts are created after that, the account from step 3. is still the default.

I have an idea how to do at least this much without extensive changes at all callers.

Would this work for you?
This is essentially what my patch does with a 1-line change, isn't it?

Meaning, if no default account exists and the first account created is one which cannot be set as a default account (i.e., canBeDefaultServer==false), EnableCheckMailAtStartUpIfNeeded() isn't called and thus no default server is set, hence Local Folders becomes the default account implicitly (which is not ideal but works until bug 342632 is fixed).

Procedures for mail accounts vary between Thunderbird and SeaMonkey. I'm making adjustments to the default-account handling for the auto-config part in bug 437139, and SeaMonkey still uses AccountWizard.js for it, which is covered (I've tested the change both against Thunderbird and SeaMonkey to make sure that everything behaves as intended).

Thus, unless I've missed something, my patch here should be everything that's needed (along with the changes in bug 437139) to make this work properly for both applications.
(In reply to :aceman from comment #2)
> 3. if a pop3/imap4 account is created now TB will automatically switch to it
> as the default account.

That's the part which currently doesn't work with Thunderbird's auto-config but which I'm fixing in the other bug. If you want to test, you'll have to apply both patches.
Blocks: 854098
OK, thanks. As long as the account wizard is used for new accounts, this could work.
The canBeDefaultServer attribute was introduced with bug 66460, where also the code in question came from hard-wiring not setting the default server for NNTP accounts. Thus, it was no longer sufficient after bug 225158 added RSS support.

Consequently, the change here to generalize that test should be made either way, regardless of fixing/improving the default account in the other bugs.
I'm moving hunk #2 of attachment 758719 [details] [diff] [review] from bug 437139 over here as it's basically fixing the same issue for the auto-config code (in addition item #3 of aceman's list in comment #2), thus it was somewhat misplaced there anyway.

For createInBackend.js, the inServer.canBeDefaultServer term corresponds to the check introduced for AccountWizard.js before. The two other terms correspond to the intial check if a default account is already set in EnableCheckMailAtStartUpIfNeeded().

Ian, from SeaMonkey's perspective this is equivalent to attachment 759438 [details] [diff] [review] given that accountcreation/* is NPOTB.
Attachment #759438 - Attachment is obsolete: true
Attachment #759438 - Flags: review?(iann_bugzilla)
Attachment #759438 - Flags: review?(bwinton)
Attachment #759766 - Flags: review?(iann_bugzilla)
Attachment #759766 - Flags: review?(bwinton)
Blocks: 437139
Blocks: 880602
No longer blocks: 854098
Blocks: 881114
Comment on attachment 759766 [details] [diff] [review]
Proposed fix (v2)

Seems to do what it says on the tin r=me
Attachment #759766 - Flags: review?(iann_bugzilla) → review+
Blake, ping for review. As it's a regression fix, it would be nice to also give this some exposure on the beta channel.
Comment on attachment 759766 [details] [diff] [review]
Proposed fix (v2)

Yeah, this also makes sense to me.  r=me.
Attachment #759766 - Flags: review?(bwinton) → review+
Thanks, push for trunk please.
Keywords: checkin-needed
Comment on attachment 759766 [details] [diff] [review]
Proposed fix (v2)

Given that comm-central is still closed due to bustages, I'm requesting the approvals in parallel.

[Approval Request Comment]
Regression caused by (bug #): bug 225158 (comment #6); bug 422814 (TB part only)
User impact if declined: Creating an RSS account before creating a mail account fails to properly register that account as the default account, which in turn is used in various context.

Testing completed (on c-c, etc.): Tested on 24.0 branch.

Risk to taking this patch (and alternatives if risky): low
Attachment #759766 - Flags: approval-comm-beta?
Attachment #759766 - Flags: approval-comm-aurora?
Closed: 10 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 25.0
Attachment #759766 - Flags: approval-comm-aurora? → approval-comm-aurora+
Mark, thanks for checking this in for comm-aurora. Since you've wontfixed the patch for status-thunderbird23 but left the comm-beta request pending, I assume that Thunderbird won't have another 23.0 beta and that it's up to SeaMonkey whether or not to take it on comm-beta for 2.20.
Attachment #759766 - Flags: approval-comm-beta?
[Approval Request Comment] (see comment #12)

This version against comm-beta has the Thunderbird-specific hunk removed.
Neil, pinging you for approval per Ian's suggestion in the meeting this morning,
Attachment #779733 - Flags: approval-comm-beta?
Flags: needinfo?(neil)
Actually it seems that I don't have Bugzilla permission to approve patches.
Flags: needinfo?(neil)
OK, then just say you approve the patch and standard8 comes around to decide the approval and finds your comment ;)
Hmm, that's turning out to be more complicated than imagined...  :-)

We have a few days before 2.20 beta 3 is due, thus if either of the friendly people with sufficient privileges could take care of it I'd appreciate it.

Comment #17 indeed sounds like Neil would have approved it if he could do so, as empowered by Ian per the IRC discussion referred to above.
Flags: needinfo?(mbanner)
Flags: needinfo?(bugspam.Callek)
So I also can't flip approval+ in mailnews core components (mental note, nag Standard8 about this some more, since after TB first-beta its always just SeaMonkey anyway)

However I'm checking in anyway since we're about to spin our final beta this cycle...
Flags: needinfo?(bugspam.Callek)
Heh, these approval flags are really picky who's flipping them... ;-)
Thanks, and I'll leave the request up for Mark to retrospectively approve.
Attachment #779733 - Flags: approval-comm-beta? → approval-comm-beta+
Flags: needinfo?(mbanner)
You need to log in before you can comment on or make changes to this bug.