705216 - Exiting email account wizard broken for mozilla.com addresses

Status: VERIFIED DUPLICATE of bug 705072

(Thunderbird :: Mail Window Front End, defect)

Description

[Mike Conley (:mconley) (:⚙️) (PTO Dec 22 - Jan 2)]

bienvenu noticed this one on trunk.

Steps to reproduce:

1)  Open up the existing email account wizard
2)  Enter a name, a [e-mail] as the email address, something as the password, and press "Continue"

What happens?

We seem to be locked in while the wizard tries to contact the Email Provider.

What's expected?

We should be able to get the mail configuration details - if we fail to get them from the Email Provider, then we should try from something else, like ISPDB.

Comment 1

[Mike Conley (:mconley) (:⚙️) (PTO Dec 22 - Jan 2)]

So I put on my gumshoes, and tracked this down as showing up *after* the comm-central nightlies generated on the 21st.

It looks like the *second* XMLHttpRequest fetch attempt for configuration details (being sent to http://www.mozilla.org/en-US/.well-known/autoconfig/mail/config-v1.1.xml?emailaddress=something%40mozilla.com) is hanging.

After some digging around, I think I've reduced this as being the result of the patch for bug 651072:  https://hg.mozilla.org/integration/mozilla-inbound/rev/0c4d3b7be17e

I also backed out https://hg.mozilla.org/integration/mozilla-inbound/rev/3a00a7c1227f and https://hg.mozilla.org/integration/mozilla-inbound/rev/d3b066c050d3 prior to backing out the patch for 651072.  Maybe it's a combination of all three that caused the problem.  I haven't determined that yet.

Anyhow, I think I've located the cause - though I don't really understand how it all works just yet.

CC'ing Ben Bucksch on this, since it looks like he's dug into fetchhttp.js before, and might have an idea why those patches are causing failures.

Comment 2

[Ben Bucksch (:BenB)]

Interesting.

Yes, I wrote all that code. But no, the code doesn't do anything related to this. It merely fetches a URL, where it expects XML, but it may get back a 404 with HTML. This is what's happening for you @mozilla.com here [1], but it will also happen for most other users.

I think that new HTML-parsing code in XHR simply has a bug causing the hang.
Personally, I don't think it's a good idea to parse the HTML at all unless the caller requests it, e.g. by calling .responseHTML or similar. XHR is mostly a protocol, but many servers respond with an HTML page when they are confused/broken, but most of the time, this error HTML page is useless for the calling app. Parsing it automatically is misguided, in most cases.


[1] Small correction: We fetch <http://www.mozilla.org/.well-known/autoconfig/mail/config-v1.1.xml?emailaddress=something%40mozilla.com>, not /en-US/, the latter is probably an automatic redirect by the site.

Comment 3

[Ben Bucksch (:BenB)]

eh, make that <http://www.mozilla.com/.well-known/autoconfig/mail/config- v1.1.xml?emailaddress=something%40mozilla.com>

Comment 4

[Masatoshi Kimura [:emk]]

Dupe of bug 705072?
HTML-parsing will be disabled unless .responseType is set to "document" once bug 705072 is fixed.

Comment 6

[Mike Conley (:mconley) (:⚙️) (PTO Dec 22 - Jan 2)]

The landing of the patch in bug 705072 has fixed this for me.  Thanks!

Comment 7

[Ben Bucksch (:BenB)]

Marking VERIFIED DUP per last comment