Have to go into Account Settings to set up the SSL bits that we use at Mozilla, and now that I've done that for SMTP and IMAP neither OK nor Cancel respond to my clicks.
Probably related: Error: smtpService is not defined Source File: chrome://messenger/content/am-smtp.js Line: 153 Pressing cmd-Q with the dialog up worked, in that it removed the dialog, but didn't actually quit the application. This is probably related to that: Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIAppStartup.quit]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: chrome://global/content/globalOverlay.js :: goQuitApplication :: line 51" data: no]
Looks like Bugzilla ate all the juicy parts of comment 0, where you mentioned the version and buildid and steps including POP or IMAP and whether it was a new profile and what you entered both in the wizard and while making changes in the account manager.
TB 3b2. I set up mail.mozilla.com for IMAP and smtp.mozilla.org via the wizard and then went into the account settings to make them both be SSL. I then tried to save. (That's my recollection, at least -- does tbird keep a setup log somewhere that I can consult?)
Nope, no logging other than the prefs that your choices create. I can't seem to reproduce in a current nightly, but then there's quite a few steps in going into the account settings to make them both be SSL, and either order or another change at the same time could be the trigger. I guess. How on earth is smtpService going to be undefined, when it's a(n egregiously unnecessary) global defined right there at the top of the same file as the function that doesn't see it? Did the .getService call fail? I don't suppose this is reproducible?
What's the format of the IMAP and SMTP usernames? Any interesting characters we're mishandling somewhere?
Both are firstname.lastname@example.org; I'll see if I can reproduce it the next time Mail.app craps out (currently on a 2-hour cycle, roughly).
I'm not sure if this is related, but the OK button on the Account Settings Panel has stopped working for me all together. The Cancel button, however, does work. I set up my accounts many, many months ago and can't remember changing anything related to SMTP nor IMAP since setting them up, so if the current bug limited to OK stopping work having to do with changes to these settings, then I guess I'll create a new bug entry. I'm running tb 188.8.131.52 under XP Home, SP3 with lastest hotfixes. I've turned off all extensions and themes and the problem continues for me. Please advise if I should create a new bug entry.
I have the same problem as Paul Brion / comment 7: OK does not work, but Cancel works. But, it only happens if I am in the account settings of an IMAP account, not an SMTP account. Though, if I switch to the JUNK panel, the OK button works. Paul, can you confirm this? I suspect that it is related to some invalid data, as I have been messing around with the prefs file (actually auto-generating it by a self-made tool...) Since the account numbers in the prefs change when I start from scratch, I have not yet found out which line in the prefs actually is the evil...
in response to Philippp's latest question to me: I can't really say, because I'm now running TB 3.0.1 under Vista64 and no longer have the problem I reported ~10 months ago.
Thanks, Paul. Hey, I just found the evil in my case: user_pref("mail.server.server2.spamActionTargetAccount", "imap://user@server"); Where "user" was from a wrong account (one that was not present in the prefs). Setting user to the corresponding login name solved the problem.
Happens to me now although was working just 30 minutes ago. First off, this bug is occurring now I presume because of my attempt to "fix" another TB bug (which I'm still searching for in Bugzilla) where I am unable to send messages via SMTP. I have 6 accounts created, all using unique SMTP servers (3 are IMAP, 3 are POP3). They all work except this one which is my work address, this means the mail server is physically located about 8 meters from my desk and the configuration I have verified to be correct with 2 of our IT managers. In an attempt to fix this, I read that deleting the questionable account may help. 1. I copied all my inbox/sent messages to my local folders. 2. I opened the Account Manager and deleted the relevant SMTP server and account. 3. Pressing OK already didn't work here... but the account was deleted and pressing Cancel was okay (I presume). 4. Restarted TBird. 5. Open Account Manager and pressing OK still does nothing.
rkent, Philippp, spamActionTargetAccount (comment 10) is cited in bug 536768 (In reply to Philippp from comment #10) > Thanks, Paul. > > Hey, I just found the evil in my case: > > user_pref("mail.server.server2.spamActionTargetAccount", > "imap://user@server"); > > Where "user" was from a wrong account (one that was not present in the > prefs). > Setting user to the corresponding login name solved the problem. WRT original report/comment 1, bug 541287 (WFM) and bug 631362 (open) mention globalOverlay
Severity: normal → major
The smtpService variable is being reworked in bug 754579. Can anybody still reproduce the problem?
Whiteboard: [CLOSEME 2012-07-01]
Yes. I just reproduced it right now, here is how: - Open Account Settings - Edit "Microsoft Live Hotmail" settings - delete username, change to username without @hotmail.com - press OK (to close SMTP server edit dialog) - press OK (to close account settings) but it is not closeable
What is "Microsoft Live Hotmail" settings ? And what is your TB version?
"Microsoft Live Hotmail" is the default auto-generated configuration when creating a Hotmail account. Sorry for not including version. I am running the latest and greatest: 12.0.1
Would you be able to make a copy of your profile and run TB15 on it to see if the problem is still there? As I said I've done some changes in the smtp dialog and that is in TB15 where the development is now.
Ok tested on 14.0a2 (May 26th build) and I can't seem to get it to fail. However, I went back to 12.0.1 and now I can't reproduce there anymore either! I seriously doubt that running the nightly build influenced this but I am unable to reproduce in either version. I will keep testing on both to see if I can't make sense of this.
14 is not 15, but it may have other fixes influencing your problem.
Oops! The link you sent me was to nightly builds for Firefox. So I Googled for nightly builds of Thunderbird and the newest I could find was for 14.x. Either way, I can't reproduce in any version at the moment. But I eventually found 15.x nightly builds in case someone else is able to test: https://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-comm-central/ I did notice though that 14.x used my original profile (located at %appdata%\thunderbird), so perhaps opening my profile in that version tweaked something in the profile which fixed it? I just did a WinMerge on my profile folders and saw quite a few changes but I also unfortunately received mail so that may have messed things up. As soon as I have a few minutes to spare, I will isolate profiles and try again with 15.x. I launched 15.x but now 12.x isn't even loading my old profile, so I'm trying to get things back to normal before commencing testing.
Yeah, sorry about the Firefox builds :) Yes, the link you found is correct for Thunderbird. You can generally copy the profile by just copying the folder with the random characters under AppData\Thunderbird\Profiles\ . And then edit AppData\Thunderbird\profiles.ini file, copy the [Profile0] section into a [Profile1] and update the name and path. Also set Default=0 in the experimental one. Also set StartWithLastProfile=0 so that TB asks you for the correct profile at each run.
Glenn, TB 14/15 (and even TB13.0) already had a partial fix that fixes your spamtarget folders if you do not use deferred inboxes. So temporarily using TB14 and then going back to 12 may exhibit what you saw (Tb14 fixed your settings and TB12 now works fine). If that is the case then bug 472959 was your problem. Fixed since TB13. That one is released now so you can safely upgrade to it. That may also apply to Philippp as he also mentions the spam pref. Still not sure what is :shaver's problem.
As the spam settings problems are handled in other bugs and the smtpService variable was removed in bug 754579, the error message in comment 1 can't happen anymore. So this bug as is probably can be closed.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WORKSFORME
Whiteboard: [CLOSEME 2012-07-01]
You need to log in before you can comment on or make changes to this bug.