583602 - JS exception during autoconfig if no network connection or Work Offline ( 0x804b0010 (NS_ERROR_OFFLINE) [nsISocketTransportService.createTransport], chrome://messenger/content/accountcreation/guessConfig.js::SocketUtil::line 1071 )

Status: RESOLVED FIXED

(Thunderbird :: Account Manager, defect)

Description

[Michael A. Pasek]

If a user attempts to cause the "autoconfig" process to fail more quickly by disconnecting or disabling his/her network connection, the following exception dialog is displayed:
"[Exception... "Component returned failure code: 0x804b0010 (NS_ERROR_OFFLINE) [nsISocketTransportService.createTransport]" nsresult: "0x804b0010 (NS_ERROR_OFFLINE)" location: "JS frame :: chrome://messenger/content/accountcreation/guessConfig.js :: SocketUtil :: line 1071" data: no]" 

The dialog gives only an option of "OK", and clicking "OK" appears to have no effect on the "autoconfig" process -- the wheels are still spinning and it's still looking for settings.  Clicking "Stop" merely brings up the exception dialog again.  The only option is to click "Cancel", which dismisses the "autoconfig" dialog.

Disabling the network connection was one of the workarounds for attempting to create a POP instead of an IMAP account in 3.1; this no longer works.

Steps to Reproduce:  Disable network connections, attempt to create new account.

Expected Results: Setup should fail as with 3.1 (Thunderbird failed to find the settings for your account), leaving the autoconfig screen in "Edit" mode.  Optionally, since being offline is now detected, that information could also be included (Thunderbird could not find your settings because you are not online).

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1

Comment 1

[Michael A. Pasek]

This may have been fixed between 3.1.1 and 3.1.2 release.  User with Windows7 & 3.1.2 says exception did not occur when network disabled (but didn't say how he disabled it).

Roland: Can you try to reproduce (I know you're running 3.1.2) ?

Comment 2

[codenamexxi]

Today, i've been seen the same error, with Thunderbird 3.1.4

I've formatted my Notebook, installed only drivers, Windows 7, Firefox, Sunbird and Thunderbird. But in Thunderbird, i get the same error and i can't create my own account!!! It's ridiculous...

Comment 3

[WADA:World Anti-bad-Duping Agency]

Next error is easily produced by "Work Offline" followed by account creation (with Tb 3.1.4). 
> [Exception... "Component returned failure code: 0x804b0010 (NS_ERROR_OFFLINE)
> [nsISocketTransportService.createTransport]"  nsresult: "0x804b0010 (NS_ERROR_OFFLINE)"
> location: "JS frame :: chrome://messenger/content/accountcreation/guessConfig.js :: SocketUtil :: line 1071"  data: no]
I saw it on 7/07 when I tried "Work Offline" as workround of problem of "Stop button takes very long to terminate server access", but didn't report to B.M.O...

Comment 5

[Michael A. Pasek]

WADA <[e-mail]> changed:
>           Severity|normal                      |minor

Actually, I'd say this is more than "minor", for two reasons:
  1) Taking the network offline is the ONLY reliable way to get the autoconfig wizard to reliably "stop";
  2) This bug makes it impossible to _configure_ an account without a network connection.

Comment 6

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #0)
> Disabling the network connection was one of the workarounds for attempting to
> create a POP instead of an IMAP account in 3.1; this no longer works.
(In reply to comment #5)
> 1) Taking the network offline is the ONLY reliable way to get the autoconfig wizard to reliably "stop";

Confirmed it.
Work Offline was workaround of that Tb 2 or former attempted to access IMAP server without SSL just after IMAP account creation even though SSL is required for the IMAP account, because Account Wizzard of Tb2 or former created IMAP account without SSL initially.
I checked with Tb 3.0, and saw that auto-config of Tb 3.0 worked well even when Work Offline status.

I thought it started to occur from Tb 3.0.0 with new auto-config. It's critical regression for us and it's rather major, because "auto-config while Work Offline" is mandatory feature of Tb 3.x for important 1) :-)

Comment 7

[Ludovic Hirlimann [:Usul]]

Guys how is this different from bug 599173 ?

Comment 8

[Michael A. Pasek]

(In reply to comment #7)
> Guys how is this different from bug 599173 ?

It's the same bug -- this one was first (599173 has been DUP'd to this one).

Comment 11

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #5)
> 1) Taking the network offline is the ONLY reliable way to get the autoconfig
>    wizard to reliably "stop";

I could experience "non-reliable Stop" of Tb 3.1.5 at last, using [e-mail] which is free mail address of US Yahoo!(as of today, @yahoo.com, @ymail.com, and @rocketmail.com are available). Even after autoconfig stopped by "Stop" button, manual change of fields was always impossible.

Autoconfig of Tb 3.1 seems confused or waiting for long time in this case.
(a) If imap.mail.yahoo.com is defined for @rocketmail.com;
IMAP server of imap.mail.yahoo.com is not officially announced/supported by Yahoo! for general mail clients, and IMAP server of Yahoo requets 'ID ("GUID" "1")' before authentication. Tb may infinitely retry in this case. See Bug 493064 for ID ("GUID" "1"), please.
(b) If imap.mail.yahoo.com is NOT defined for @rocketmail.com;
There is no IMAP/POP3 server of ...rocketmail.com. There are servers who receive mail data from MTA only. Autocongig of Tb 3.1 may wait response for very long time or forever.
> dig @dns0 mx rocketmail.com
> ;; QUESTION SECTION:
> ;rocketmail.com.                        IN      MX
> ;; ANSWER SECTION:
> rocketmail.com.         798     IN      MX      1 a.mx.mail.yahoo.co
>(snip)
> rocketmail.com.         798     IN      MX      1 k.mx.mail.yahoo.co
> ;; ADDITIONAL SECTION:
> a.mx.mail.yahoo.com.    327     IN      A       67.195.168.31
>(snip)
> k.mx.mail.yahoo.com.    901     IN      A       98.139.54.60

Simplest way of "Manual Setup".
(1) Specify non-existent server(no entry in DNS) in mail address.
    e.g. <your-name>@z.z.z
(2) Click "Stop" twice (one for mail server, one for SMTP).
    "Stop" always worked immediately well in my environment. 
(3) Change required fields.
    Hostname/Username of IMAP/POP3 should be set correctly at this step,
    in order to avoid .realhostname/.realuserName != .hostname/.userName
    since initial definition.
(4) "Manual Setup".
    Mail address change and account name(label) change and needed
    in addition to required changes when "Work Offline" way is used,
    because wrong mail address is specified at step (1).

Comment 12

[rsx11m]

Can someone still reproduce this with a Miramar 3.3 alpha 3 or current nightly, now that bug 549045 has redesigned the account-setup wizard?

Comment 13

[David :Bienvenu]

I'll try to look into this - I think if we're offline, we should disable probing, and enable manual config.

Comment 14

[David :Bienvenu]

Attachment: proposed fix

this patch seems to work. I think it's fairly clear that the patch only changes the behavior when we're offline, so it's unlikely to create any regressions for when you're online. This does add a new string, so it would need to get reviewed pretty quickly to make 3.3

Comment 15

[Blake Winton (:bwinton) (:☕️)]

Comment on attachment 531162 [details] [diff] [review]
proposed fix

>+++ b/mail/locales/en-US/chrome/messenger/accountCreation.properties
>@@ -26,18 +26,18 @@ looking_up_settings_halfmanual=Looking u
>-# LOCALIZATION NOTE(failed_to_find_settings): %1$S will be the brandShortName.
>-failed_to_find_settings=%1$S failed to find the settings for your email account.
>+# LOCALIZATION NOTE(guessed_settings_offline) User is offline, so we just took a wild guess and the user will have to enter the right settings.
>+guessed_settings_offline=You are offline. We guessed some settings but you will need to enter the right settings.
> manually_edit_config=Editing Config

We still use the "failed_to_find_settings" property in mailnews/base/prefs/content/accountcreation/emailWizard.js, so removing it probably isn't the right thing to do.

>+++ b/mailnews/base/prefs/content/accountcreation/emailWizard.js
>@@ -377,16 +379,26 @@ EmailConfigWizard.prototype =
>+    // If we're offline, we're going to disable the create button, but enable
>+    // the advanced config button if we have a current config.
>+    if (Services.io.offline) {
>+      if (this._currentConfig != null) {
>+        _show("advanced-setup_button");
>+        _enable("advanced-setup_button");
>+        _show("create_button");
>+        _disable("create_button");

I tried this, and found that having both the Manual and Advanced Settings available to be confusing.  I would recommend disabling the Manual Settings, but that wouldn't let the user choose between POP and IMAP (because we can't choose that afterwards).  So, what if we added an incomingAlternative to the guessed config?  Something like:
    resultConfig.incomingAlternatives = [];
    resultConfig.incomingAlternatives.push({
      hostname: "imap." + domain,
      username: resultConfig.identity.emailAddress,
      type: "imap",
      port: 443,
      socketType: 3,
      auth: Ci.nsMsgAuthMethod.passwordCleartext
    });
works, but exposes a bug in which radio button gets selected when POP is listed first.  Of course, I don't know if we want to put POP as the default selection if the user can choose it easily, so we might just list IMAP first as a workaround…

>+++ b/mailnews/base/prefs/content/accountcreation/guessConfig.js
>@@ -97,17 +98,35 @@ function guessConfig(domain, progressCal
>+  // If we're offline, we're going to pick the most common settings.
>+  // (Not the "best" settings, but common).
>+  if (Services.io.offline)
>+  {
>+    resultConfig.source = AccountConfig.kSourceUser;
>+    resultConfig.incoming.hostname = "mail." + domain;
>+    resultConfig.incoming.username = resultConfig.identity.emailAddress;
>+    resultConfig.outgoing.username = resultConfig.identity.emailAddress;
>+    resultConfig.incoming.type = "pop3";
>+    resultConfig.incoming.port = 110

You forgot the ; here…

Finally, the dialog with the new text needs more padding on the right side.

Thanks,
Blake.

Comment 16

[David :Bienvenu]

ugh, did not mean to remove any strings. Right, I couldn't remove manual settings because the user needs to be able to choose between imap and pop3. If anything, advanced should probably be disabled until they've had a chance to do so...

I could switch to IMAP over POP3, but since we can't do anything to verify the settings, I wanted to pick the more common one. But I doubt I can fix the radio button bug...

Comment 17

[David :Bienvenu]

Attachment: patch addressing comments

Comment 18

[Blake Winton (:bwinton) (:☕️)]

Comment on attachment 531344 [details] [diff] [review]
patch addressing comments

>+++ b/mail/locales/en-US/chrome/messenger/accountCreation.properties
>@@ -29,16 +29,19 @@ found_settings_isp=Configuration found a
> manually_edit_config=Editing Config
>+# LOCALIZATION NOTE(guessed_settings_offline) User is offline, so we just took a wild guess and the user will have to enter the right settings.
>+guessed_settings_offline=You are offline. We guessed some settings but you will need to enter the right settings.
>+manually_edit_config=Editing Config

You've duplicated this string.  :)

>+++ b/mailnews/base/prefs/content/accountcreation/guessConfig.js
>@@ -97,17 +98,43 @@ function guessConfig(domain, progressCal
>+  // If we're offline, we're going to pick the most common settings.
>+  // (Not the "best" settings, but common).
>+  if (Services.io.offline)
>+  {
>+    resultConfig.source = AccountConfig.kSourceUser;
>+    resultConfig.incoming.hostname = "mail." + domain;
>+    resultConfig.incoming.username = resultConfig.identity.emailAddress;
>+    resultConfig.outgoing.username = resultConfig.identity.emailAddress;
>+    resultConfig.incoming.type = "imap";
>+    resultConfig.incoming.port = 143;
>+    resultConfig.incoming.socketType = 3; // starttls
>+    resultConfig.incoming.auth = Ci.nsMsgAuthMethod.passwordCleartext;
>+    resultConfig.outgoing.hostname = "smtp." + domain;
>+    resultConfig.outgoing.socketType = 1;
>+    resultConfig.outgoing.port = 587;
>+    resultConfig.outgoing.auth = Ci.nsMsgAuthMethod.passwordCleartext;

If you wanted to group the incoming and outgoing settings into a couple of objects, like we do for the incomingAlternative, that might be cool, but I wouldn't insist on it.

And other than that, I like it.  r=me with the string nit fixed.

Thanks,
Blake.

Comment 19

[David :Bienvenu]

fixed on trunk - I fixed the string nit. I have a mozmill test in progress, and I'll try to finish that soon.

Comment 20

[Ben Bucksch (:BenB)]

We shouldn't let guessConfig.js return a fake config, but rather just fail. This will drop us into the manual config, and that will prefill the entry fields. There's no need to make a fake config.

The UI that it uses with the current patch is intended only for cases where we actually *found* a config.

Comment 21

[David :Bienvenu]

I believe that's what I wanted to do, but Blake wanted to go straight to account settings.

Comment 22

[Ben Bucksch (:BenB)]

But that's not what the patch does.
1. Furthermore, the user should change the values before entering Advanced Config, because otherwise this "wild guess" is final in the profile, e.g. folder names.
2. Last but not least, there should be a warning that the user should go online before configuring accounts. It may not be intentional that he's offline.
3. And, finally, we cannot rely on Services.io.offline, it's not giving the correct answer in many cases, e.g. with a DSL router with local LAN. In other words, the fix here doesn't actually fix it in many cases (unless the user is aware of File|Offline menu entry, which most are not, and that this setting now has an effect on this wizard).

I think these concerns are serious enough to re-do the patch.

I think we should instead:
1. When we make a network connection to contact the ISPDB, and there is no Internet connection, we will get back a certain error code. We actually do pass that back to emailWizard.js already. All we need to do is catch that specific error situation.
2. Show a warning "
It appears that you are not offline, i.e. not connected to the Internet, because we can't reach the configuration server. In order to get the best configuration and be able to verify it, please go online before setting up an account. If for some reason that is impossible, you can manually enter the configuration and finish by clicking "Advanced config", but that is not recommended.

Please go online.
[I cannot go online] [I will connect to Internet]
"
3. If the user says he can't go online, to straight to manual mode (as if configs failed) and allow to skip the "Re-Test", i.e. enable Advanced Config button after the user entered a syntactically valid hostname. I.e. the only change we need to do is to not force a "Re-Test" before enabling the "Advanced Config" button.

Comment 23

[Mark Banner (:standard8)]

This bug has already landed for 5.0b1, I don't see us backing the patch out, as I think the UX is much better than the total failure we had before (though Blake can override me if he wishes).

Therefore remarking as fixed - we should deal with follow-up issues in separate bugs, especially as some of the proposals include strings which we won't be able to take in 5 or 6.

(In reply to comment #22)
> 3. And, finally, we cannot rely on Services.io.offline, it's not giving the
> correct answer in many cases, e.g. with a DSL router with local LAN. In
> other words, the fix here doesn't actually fix it in many cases (unless the
> user is aware of File|Offline menu entry, which most are not, and that this
> setting now has an effect on this wizard).

Agreed that's probably not exclusively good enough, but it is a much better start, and we should rely on Services.io.offine and then on network failure.

Comment 24

[Ben Bucksch (:BenB)]

OK, then bug 599173 is the followup.