On Thu, Jan 3, 2013 at 2:33 PM, Andrew Sutherland <[email protected]> wrote: > The e-mail (packaged) app does an asynchronous XHR to check whether there is > an autoconfig file in its local /autoconfig/ directory before moving on to > asking the internet for answers. So if you type in "[email protected]" for your > e-mail address, we will do an XHR for "/autoconfig/yahoo.es".
And you are doing this from a page with a URL that looks something like app://email.gaiamobile.org/index.html Is that correct? I.e. you are doing an XHR request to something like app://email.gaiamobile.org/autoconfig/yahoo.es > Previously, our onload() event would fire with the failure when a match was > not found. However, it now appears that in the nsXMLHttpRequest::Send call, > that the mChannel->AsyncOpen is newly failing with NS_ERROR_FILE_NOT_FOUND. > This ends up being thrown as 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] Is this only happening if the "autoconfig/yahoo.es" file doesn't exist in the app package? I.e. is the load completing successfully if the file exists. > From https://bugzilla.mozilla.org/show_bug.cgi?id=804395, it seems like we > want XHR to not change in behaviour between when something is run as a > packaged app versus when it is run on the web. So this seems undesirable. > This may also be a spec violation since what is happening only seems > suitable for a synchronous XHR, although I have not done a deep read of the > XHR spec lately and only skimmed it today. > > My desired outcome from this e-mail is if someone could indicate whether the > exhibited behaviour is desired, I agree that throwing from the send() call like that is not desired. And I think that it is a violation of the XHR spec. > if we think this changed recently, and if > anyone has an idea of what bug regressed this if so. (I've done some quick > scanning, but there are many bugs touching the general area of code, but > none are jumping out at me very obviously.) > > https://bugzilla.mozilla.org/show_bug.cgi?id=826468 is currently tracking > the e-mail problem. We aren't really sure when this might have regressed > right now. A guess is that this is a regression from bug 815523. If that is indeed the case, mark bug 826468 as blocking bug 815523 and nominate it for for blocking-basecamp. But I am worried that if this is too complicated to fix (hard to say without knowing what's broken) then we might not be able to fix it in time for launch. / Jonas _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
