If you apply this patch queue (builds available soon): https://github.com/wanderview/gecko-patches/tree/serviceworkers Then do the following: 1) Enable e10s mode 2) Go to https://jakearchibald.github.io/trained-to-thrill/ 3) Hit refresh 4) Examine the web console You will see this error: Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://api.flickr.com/services/rest/?method=flickr.photos.search&extras=description&format=json&api_key=f2cca7d09b75c6cdea6864aca72e9895&text=train%20station&license=4%2C5%2C6%2C7&content_type=1&nojsoncallback=1&per_page=10. (Reason: CORS header 'Access-Control-Allow-Origin' missing). Its difficult to see whats happening because the requests do not show up in the devtools network panel.

Any ideas if this CORS failure is legitimate or not? Jake seemed pretty certain all of these should pass the CORS the last time I asked him about it.

Note that the fetch event code currently does not set any CORS flag on the Request object if RespondWith is called. I was planning to fix that as a followup.

Flickr sends all the right CORS responses if the request is properly set. The request's mode has to be set to cors-with-forced-preflight in certain cases (depends on the HTML element in question). Unfortunately the living standard hasn't been updated to use the fetch spec yet, so this may require specific clarifications from :annevk.

we're not tracking bugs on new development

I am hitting this issue with a non e10s build as well.

I got this a few times on mac desktop non-e10s just now. I hit refresh a few times and it went through... which kind of sucks. We must have a timing issue somewhere?

This is nothing so painful to debug like a timing issue :) Bug 1134462, Bug 1134465.

Ben, so I looked at this, and in the TtT serviceworker when it uses the Accept header to determine if to serve from the Cache API (cache.match), that is when the CORS failure happens. The response returned by cache is some sort of error (in the Necko layer I get the nsIRequest's status (retrieved using GetStatus()) as an error -2142568446). It is possible the cache is not creating Responses properly. As for the image stalling thing, I haven't figured that out yet.

After some more digging, this isn't really a CORS failure at all, or a cache failure. This will happen whenever something rejects the promise. When the respondWith() Promise rejects, the channel is aborted with NS_BINDING_ABORTED. I verified that the nsresult in CORSListener is indeed the error code representing NS_BINDING_ABORTED (ignore the -2142... that was a formatting error). Then CORSListener complains because the underlying request was aborted, hence the warning. I'm not sure what we can do here. The best thing would be for devtools to indicate that the promise was rejected. We could add another error message to CORS that specifically points this out.

Do we know yet what is causing the underlying promise to get aborted?

In general it can be anything, including errors in the JS. In this case, it looks like match() is rejecting it, because it happens in that case of |return cache.match(request)|

I believe |caches.match()| resolves undefined. Nikhil tells me that our fetch event respondWith() code treats this as a cancellation. This probably only happens some of the time because trained-to-thrill starts two requests in parallel; one to network and one to cache. If the cache one triggers a failure first, then we don't get the network response for some reason. So we probably need a better error message in nsCORSProxyListener on cancelation or error. But we also need to figure out why the cancelation of the cache request also stops the network request.

Actually, maybe this is just a bad error message. The trained-to-thrill "derailed" message might be happening in e10s for other reasons.

respondWith() step 9.3.2 states that if the promise was resolved with something that is not a Response, it is an error and the fetch is canceled. Now that we have Cache, I no longer see this.