Re: Service Worker issues

2016-07-27 Thread Ben Kelly
On Wed, Jul 27, 2016 at 11:57 AM, Sam Ruby  wrote:

> The following is a mix of spec and implementation issues that I
> encountered in my as-of-yet unsuccessful attempt to make use of service
> workers in the ASF Board Agenda tool.
>

First, let me say thank you for the feedback!  Its very helpful to hear
from developers.


> 1) the "offline fallback" use case for Service Workers involves
> intercepting fetch requests, issuing the request, and then recovering from
> any errors that may occur.  Unfortunately, issuing the event.request will
> not faithfully reproduce the original navigate request, in particular,
> credentials are not included.
>

Yes, there have been a lot of bugs that fall into this category.  Its
re-creating the Response object from the browser native network stack is
particularly prone to missing information.

If you can be more specific about the type of request you are seeing this
with we can write a WPT test and make sure it doesn't regress.


> 3) event.request.headers.get("Authorization") is available on Firefox but
> not on Chrome.
>

Is this Authorization header on the original request being set by the
browser or manually in an XHR/fetch?

Looking at the spec the service worker should probably *not* see
Authorization headers added by the browser.  That's supposed to happen
after the service worker interception.


> 4) cache.keys() is supposed to return a promise.  On both Firefox and
> Chrome, cache.keys() returns an empty array instead.  cache.matchAll() can
> be used to get all of the responses, but not the keys.
>

Can you share the code you are using?  It returns a promise in our tests
and in my quick check in the console:

caches.open("blog - 2016-06-10 14:14:23 -0700").then(c => c.keys())
Promise { : "pending" }


> 5) calling registration.unregister() followed by
> navigator.serviceWorker.getRegistrations() will still return a list
> containing the now unregistered service worker in both Firefox and Chrome.
>

Are you waiting for the promise returned by unregister() to resolve?


> 6) EventSource is available to service workers in Chrome but not in
> Firefox.  Using importScripts in an attempt to load the Yaffle polyfill
> doesn't work.
>

We have a bug filed for this:

https://bugzilla.mozilla.org/show_bug.cgi?id=1267903

Thanks again.

Ben


Service Worker issues

2016-07-27 Thread Sam Ruby
The following is a mix of spec and implementation issues that I 
encountered in my as-of-yet unsuccessful attempt to make use of service 
workers in the ASF Board Agenda tool.


1) the "offline fallback" use case for Service Workers involves 
intercepting fetch requests, issuing the request, and then recovering 
from any errors that may occur.  Unfortunately, issuing the 
event.request will not faithfully reproduce the original navigate 
request, in particular, credentials are not included.


2) passing credentials: 'include' on fetch requests within a service 
worker will succeed if the browser has access to the credentials (e.g. 
due to prompting the user earlier in the browser session).  If the 
credentials are not present, Firefox will prompt for this information. 
Chrome will not.  This is a showstopper for offline access to an 
authenticated web page with Chrome.


3) event.request.headers.get("Authorization") is available on Firefox 
but not on Chrome.


4) cache.keys() is supposed to return a promise.  On both Firefox and 
Chrome, cache.keys() returns an empty array instead.  cache.matchAll() 
can be used to get all of the responses, but not the keys.


5) calling registration.unregister() followed by 
navigator.serviceWorker.getRegistrations() will still return a list 
containing the now unregistered service worker in both Firefox and Chrome.


6) EventSource is available to service workers in Chrome but not in 
Firefox.  Using importScripts in an attempt to load the Yaffle polyfill 
doesn't work.


Advice on how to proceed with these issues (filing bugs on the spec 
and/or one or more implementations, perhaps?) would be greatly appreciated.


Thanks!

- Sam Ruby