26.54 KB, application/octet-stream
109.84 KB, image/jpeg
1.10 KB, patch
|Details | Diff | Splinter Review|
3.13 KB, patch
Philip Chee: feedback-
Magnus Melin: feedback+
|Details | Diff | Splinter Review|
As Susanne Jaeger reported in the German MailNews newsgroup, after following a news:// URL you'll be unable to select the account type (mail, feeds, news) when opening the Account Wizard (either from the File menu or Account Settings). Instead you'll be taken directly to the Identity wizard page and from there to the Server Information wizard page. At least the Server Information page will show the account data matching the newsgroup subscribed to through the news:// URL. You will not be able to finish the wizard without changing the Newsgroup Server name. However, even finishing the wizard won't solve the problem. Problem source: The account is declared invalid, i.e. the mail.server.serverX.valid pref is set to false (where X is the matching account). Root cause: unknown, yet to be determined. Accounts created in the way described above are either missing a validation step or the corresponding function is broken. Workarounds: Set mail.server.serverX.valid to true or delete invalid news account. Backtrace: 1. AccountWizard.js: checkForInvalidAccounts() calls GetPageData() which sets gPageData 2. aw-accounttype.js: also calls GetPageData() which returns the created news server's data because gPageData is still pointing to that.
The faulty behaviour in the Account Wizard is similar to bug 521627.
Found this problem myself on SeaMonkey 2.0.1. It is somewhat nasty, because there is no clue about the reason why suddenly the account manager stops working right. Is there something we (users) could do to help fixing this problem (providing a fixed set of steps, activating mail debugging logs, etc.)? BTW, this bug affects SeaMonkey 2.0 branch, so maybe the version field should be changed?
(In reply to comment #3) > Found this problem myself on SeaMonkey 2.0.1. BTW, in my case clicking in a news:// link didn't CREATE a fake news account; instead, MODIFIED one of my newsgroup accounts, renaming it and changing the From: e-mail address associated to it.
Do you have the prefs.js files before and after this step? I.e. could you please post an anonymized diff?
(In reply to comment #5) > Do you have the prefs.js files before and after this step? I.e. could you > please post an anonymized diff? I'll take a look (I have two synchronized machines through an external hard disk, and it could be that one of them still have the previous version).
Created attachment 419791 [details] Old, new prefs.js and diff, all anonymized (Father-prefs.js is the affected by this bug)
Today I took the time to find a regression window for this. Result: Last known good: 2009-01-09 Broken since: 2009-01-10 Note that "good" here means that "New > Account" fails the first time after trying to subscribe to a newsgroup and canceling in the following dialog, but afterward the account wizard works again, whereas "broken" means that the account wizard stays broken even if you try "New > Account" again. Probable causing changeset: http://hg.mozilla.org/comm-central/rev/b78eb7642489 (bug 538414) My test case was: 1. create a new profile 2. create a Feed account (or any other, but it's fast to do it this way) 3. subscribe to a newsgroup, but cancel the dialog 4. try to create a different account (check the first screen) 5. cancel the dialog and repeat step 4.
Relnoted, see bug 656719 comment 25.
This could be a security issue. I tried to create a new email account, but could not because it was defaulting to a news account, so I gave up and switched to a standalone copy of Thunderbird to set up the mail. However, I now find that when replying to a Newsgroup item, it has picked up the private email address that I was trying to set up. This has exposed a personal email address that I do not use for newsgroups ( to avoid spam etc). Since this problem has been known about for nearly three years, it should have been fixed by now.
I'm having this problem with adding news servers, but not through an URL, through the settings in SM 2.8. I can't add but one news server now, because it's really badly broken now. Sometimes what I add doesn't show up at all in SM. Other times it will, but it has changed the original account that I had. It has given me too many invalid responses to list. Does no one care that they have rendered a core function of SM unusable?
I've just run into this issue in SM 2.22.1 on OS X 10.7.5. Nasty!
REPRODUCIBLE with SeaMonkey 2.39a1 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:42.0 from official download area) Gecko/20100101 Firefox/42.0 (Classic Theme) on German WIN7 64bit 1. Launch SeaMonkey via Profile manager from command line 2. Create blank new profile "Newsgroupstest2" → Launch SeaMonkey → confirm default client for all applications → confirm changes requiring WIN admin permissions 3. on <http://www.seamonkey-project.org/dev/get-involved> in left selection pane click "Communitiy and support" for <http://www.seamonkey-project.org/community> 4. Click Link Newsgroup: mozilla.support.seamonkey → confirm confirm 'would you like to subscribe' with [ok] » "Identity" dialog appears instead of account type selection dialog 5. [Cancel] will create account and subscribe "mozilla.support.seamonkey" with invalid identity entries, but postings will be downloaded. I changed "Version" to ease recognition of appearance therube asked me to test this one in "Bug 1179680 - Lost ability to add new mail/news accounts". Effects here look similar, but my problem there did not appear in 2009
@Hb: May be you can explain your Version modification?
While I'm not :Hb, here's the reasoning: * The 2.0 branch is long gone, it has been discontinued years ago. "SeaMonkey 2.0 Branch" is not including all 2.x versions as you might think, but only the 2.0.x ones. * Version should show the latest affected version. Until this bug gets fixed, all versions are affected, i.e. Trunk is the correct value for the field for the time being. For the same reason, setting any of the status tracking flags is pointless, too, since you might then as well set those for all past and future versions, too.
Created attachment 8707885 [details] Clipboard.jpg I stumbled again over this bug when I tried to add a mail account today. I think the problem is the leftover valid setting for the news server. Usually you can see the pref for a short time when you create an account manually. It's the string pref in the lower half of the picture. When you cancel the subscription in the way Rainer did it in Comment 15 you end up with a mail.server.serverX.valid boolean pref set to false. This seems to confuse the heck out of the account wizard. The simple solution seems just to delete the pref. The not so simple solution would be to make sure that every mail.server.serverX has such a valid pref regardless of it's setting. This seems to work too.
Created attachment 8707887 [details] [diff] [review] accountwizard.patch Simple patch which just deletes the pref during startup. I do not think it's reviewable yet because I am not sure it should be in the migrate js. Was just convenient there because all servers are read here. Any comments where it should be or if this is even the right approach? Works fine btw. Tested it with a private build. FRG
(In reply to Frank-Rainer Grahl from comment #20) > Created attachment 8707885 [details] > Clipboard.jpg > > I stumbled again over this bug when I tried to add a mail account today. > > I think the problem is the leftover valid setting for the news server. > Usually you can see the pref for a short time when you create an account > manually. It's the string pref in the lower half of the picture. > > When you cancel the subscription in the way Rainer did it in Comment 15 you > end up with a mail.server.serverX.valid boolean pref set to false. This > seems to confuse the heck out of the account wizard. The simple solution > seems just to delete the pref. The not so simple solution would be to make > sure that every mail.server.serverX has such a valid pref regardless of it's > setting. This seems to work too. Let's ask mkmelin I think one possible place would be nsMsgAccountManager::LoadAccounts() http://mxr.mozilla.org/comm-central/source/mailnews/base/src/nsMsgAccountManager.cpp?rev=1cb65d027ed4&mark=1188-1192#1188
Yeah that looks like a good spot to me.
(In reply to Magnus Melin from comment #23) > Yeah that looks like a good spot to me. Frg: do you want to try moving your patch to?: http://mxr.mozilla.org/comm-central/source/mailnews/base/src/nsMsgAccountManager.cpp?rev=1cb65d027ed4&mark=1209-1210#1207
Ratty, sure can do. Not this week but with a bug from 2009 it can eventually wait a little longer :) But not sure if it fixes all the instances. This one might have been a different one: http://forums.mozillazine.org/viewtopic.php?f=40&t=2995769 Did anyone else who did run into the problem checked if it's caused by the .valid prefs?
Created attachment 8753546 [details] [diff] [review] 521861-Account_Creation.patch
Comment on attachment 8753546 [details] [diff] [review] 521861-Account_Creation.patch Review of attachment 8753546 [details] [diff] [review]: ----------------------------------------------------------------- ::: mailnews/base/src/nsMsgAccountManager.cpp @@ +367,5 @@ > } > } > > +void > +nsMsgAccountManager::CleanServerValidState() nsresult is usually used even if we might not care too much about the return value atm. @@ +376,5 @@ > + if (NS_FAILED(rv)) > + return; > + > + nsCOMPtr<nsIPrefBranch> prefServer; > + if (prefService) you already know you have a prefService since rv succeeded. Or if you're paranoid, check it where you check the rv code @@ +385,5 @@ > + } > + > + nsAutoCString serverKey; > + > + // Loop over first 99 mail.server.server* entried and delete .valid entries. maybe mail.account.lastKey + some?
Comment on attachment 8753546 [details] [diff] [review] 521861-Account_Creation.patch > + nsresult rv; > + nsCOMPtr<nsIPrefService> prefService(do_GetService(NS_PREFSERVICE_CONTRACTID, > + &rv)); If you want to wrap at 80cols: nsCOMPtr<nsIPrefService> prefService = do_GetService(NS_PREFSERVICE_CONTRACTID, &rv); > + if (NS_FAILED(rv)) > + return; > + > + nsCOMPtr<nsIPrefBranch> prefServer; nsCOMPtr<nsIPrefBranch> prefBranch; > + if (prefService) You don't need to check for prefService if you have already done NS_FAILED > + nsAutoCString serverKey; > + > + // Loop over first 99 mail.server.server* entried and delete .valid entries. prefBranch->GetChildList(...) + serverKey.AppendInt(lastKey); + serverKey.AppendLiteral(".valid"); + // Just delete the 'valid' pref. Don't check if it exists. + prefServer->ClearUserPref(serverKey.get()); StringEndsWith(.. ".valid") Reference: http://mxr.mozilla.org/comm-central/source/mailnews/base/src/nsMsgTagService.cpp?rev=ff603e79f92a#160