Desired regression in behaviour for XHR for NS_ERROR_FILE_NOT_FOUND for app protocol?

[Andrew Sutherland]

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
"b...@yahoo.es" for your e-mail address, we will do an XHR for
"/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]

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, 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.

Andrew

[Jonas Sicking]

On Thu, Jan 3, 2013 at 2:33 PM, Andrew Sutherland
<asuth...@asutherland.org> 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 "b...@yahoo.es" 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

[Andrew Sutherland]

On 01/03/2013 11:20 PM, Jonas Sicking wrote:
> On Thu, Jan 3, 2013 at 2:33 PM, Andrew Sutherland
> <asuth...@asutherland.org> 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 "b...@yahoo.es" 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

Yes, exactly.

Here's an example of what the unit tests do; the newly failing case was
step 1:
https://github.com/mozilla-b2g/gaia-email-libs-and-more/blob/master/test/unit/test_autoconfig.js#L399

> 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.

Right. If the file exists, everything is A-OK. If the file does not
exist, the exception gets thrown after doing some
nsJARChannel::LookupFile and nsJARChannel::AsyncOpen stuff. In earlier
testing on the device rather than b2g-desktop, it did seem like
sometimes an exception would not be thrown. I am assuming that memory
pressure or something like that caused the JAR cache to be flushed .

> 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.

It does seem a little edge-casey and potentially annoyingly complex.
Jim Porter has already landed the simple workaround of wrapping the
send() call in a try/catch, so the e-mail app will be okay again as of
tomorrow.

Andrew