Pre-Condition: create an account in yahoo.es Repro steps: 1. Open email app 2. Configure a new email account with the domain yahoo.es ACTUAL RESULT: The Yahoo.es account unable to set up there is no error message it is just infinite spinner indicator on a screen with message "please wait while your account is set up" (see pic) EXPECTED RESULT: The account must be configured correctly Similar issue were happening on hotmail.es account and it was fixed - Bug 813473 - but Hotmail is active sync and yahoo uses IMAP. To make a hotmail.es account, click on the "Sign up now" button on the hotmail page, and then change the "EN-US" in the URL to "ES-ES" or use this link: https://signup.live.com/signup.aspx?wa=wsignin1.0&rpsnv=11&ct=1357250106&rver=6.1.6206.0&wp=MBI&wreply=http%3a%2f%2fmail.live.com%2fdefault.aspx&id=64855&cbcxt=mai&snsc=1&bk=1357250107&uiflavor=web&mkt=ES-ES&lc=1033&lic=1 It will ask you for zip code you can find it here:http://zipcodes.guide-spain.com/Madrid/Madrid or just use account I created nickdee77@yahoo.es / pass: QQ111111 Also just for a difference I put nickdee77@yahoo.com instead of nickdee77@yahoo.es in settings and it worked immediately (even it is ".es" account not ".com")

according to Andrew Sutherland - - from the log it seems like there might be a gecko platform issue or a systemic problem in our auto-config mechanism. - able to reproduce this on today's build too. It seems very specific to the ".es" suffix. I got the same failure for the made-up "zxdfghpdfg.es" but not the made-up "zxdfghpdfg.js"

Seems like same issue happens with AOL email repro on 2 devises with account Nickdeetest5@aol.com / Pass: QQ111111 related?

There appears to be a platform regression in how XHR is behaving in the cases where no such file exists. I sent an e-mail to dev-b2g asking if the new behaviour is intentional and trying to get regression finding help. What is currently happening is that xhr.send() is throwing an exception: [Exception... "File error: Not found" nsresult: "0x80520012 (NS_ERROR_FILE_NOT_FOUND)" location: "JS frame :: app://email.gaiamobile.org/js/ext/gaia-email-opt.js :: getXmlConfig :: line 35948" data: no] This is because the child process is now able to synchronously resolve that the file does not exist, likely owing to the jar cache. We should now currently expect that only the following domains will work: $ ls apps/email/autoconfig/ gmail.com googlemail.com hotmail.com hotmail.co.uk hotmail.es hotmail.it live.com live.de live.it mozilla.com outlook.com google.com hotmail.co.jp hotmail.com.br hotmail.de hotmail.fr live.co.jp live.co.uk live.fr live.jp msn.com yahoo.com Regardless of the platform issue, we should probably wrap our xhr.send call in a try and have it trigger an error/failure if it throws.

Well, this thankfully solves the mystery of why it was working for me. I'd forgotten to update my auto-updater for b2g and was still on mozilla-beta, not mozilla-b2g18.

Jason, this might be something you could look at? Sounds like something is throwing from AsyncOpen for an app:// URL, so potentially a regression from bug 815523

Here's a PR for a workaround in the email app: https://github.com/mozilla-b2g/gaia-email-libs-and-more/pull/110

Triage: BB+, C4, p3

The workaround is checked in: https://github.com/mozilla-b2g/gaia/pull/7296 Since this is no longer breaking the email app, we probably don't need to be blocking-basecamp anymore. I'm leaving this open though so that we can talk about fixing this in the XHR implementation.

Yeah, I would at least like to get an understanding of what exactly regressed here. It's probably something that affects 3rd party apps, so I'd like to understand to what extent.

Please open a new issue in plateform.

(In reply to David Scravaglieri [:scravag] from comment #11) > Please open a new issue in plateform. Filed bug 827243.

Verified as Dupe

this bug was Reported: 2013-01-03 and bug 827549 Reported: 2013-01-07 (4 days later)so the other bug suppose to be a dup. How ever this issue is resolved as far as user able to automatically set up account nickdee77@yahoo.es / pass: QQ111111 but AOL account mentioned here as well still having issue with automatic set up. Since bug 827549 is specific about AOL email we can close this one and keep that one open to track AOL set up issue.