w3c / ServiceWorker

Service Workers
https://w3c.github.io/ServiceWorker/
Other
3.63k stars 314 forks source link

Create F2F agenda - 7 November 2017 #1206

Open jakearchibald opened 6 years ago

jakearchibald commented 6 years ago

Location

TPAC, Burlingame.

Agenda

Push API

I don't know the details, but I believe the Safari folks have some concerns around the push API, so let's go through that first, timeboxed to an hour.

Changes & bugs

Interesting feature requests

jungkees commented 6 years ago

Client API and Navigate-hook

The latest agreement on FetchEvent (https://github.com/w3c/ServiceWorker/issues/1091#issuecomment-311023682):

Proposal of not exposing reserved clients: #1216.

We are here now. I'd like to discuss:

Issues:

jakearchibald commented 6 years ago

@jungkees cheers! I've added the stuff I've been looking at so far to the OP. I'll merge yours into that.

I'm sweeping through open issues today.

wanderview commented 6 years ago

We're trying to implement https://github.com/whatwg/fetch/pull/146 and ran into a potentially thorny spec issue in https://github.com/whatwg/fetch/pull/146#issuecomment-341710548. Might be worth talking about in person.

tomayac commented 6 years ago

How do people feel about discussing “meaningless” Accept headers like */* for images in Firefox that make dealing with such requests in Service Workers hard and encourage relying on file extensions, especially as there is no consistency among how browsers deal with this.

wanderview commented 6 years ago

How do people feel about discussing “meaningless” Accept headers like / for images in Firefox that make dealing with such requests in Service Workers hard and encourage relying on file extensions, especially as there is no consistency among how browsers deal with this.

We can discuss it, but standardizing Accept headers is a bit orthogonal to service workers. I recommend raising a fetch spec issue to investigate alignment between browsers on Accept headers.

tomayac commented 6 years ago

While it applies to Ajax situations like fetch and XMLHttpRequest, the issue applies to all other static “fetching” scenarios as well, be it link, img, a, etc. Dealing with it in the context of the Fetch API alone seems too limited, at least from my point of view.

jakearchibald commented 6 years ago

@tomayac the fetch spec deals with all browser fetching, not just the fetch API.

jakearchibald commented 6 years ago

I've moved the push API stuff to the morning, so @beverloo can join.

wanderview commented 6 years ago

All spec'd browser networking loading goes through the fetch specification (modulo old specs not updated yet). Not just the fetch() API.

tomayac commented 6 years ago

Thanks both for the clarification. I guess fetch spec issue(s) is the way to go then.

jakearchibald commented 6 years ago

Planning to start around 09:00 tomorrow.

delapuente commented 6 years ago

Sorry to miss this F2F. Have a really nice and productive session!

jakearchibald commented 6 years ago

@wanderview points out that we would benefit from better tests for the cache API.

jakearchibald commented 6 years ago

Action: Add notes about cache sizes + opaque responses. But diversity in mitigation is welcome.

jakearchibald commented 6 years ago

Action: Built a test that creates a same-origin worker, but in the service worker fetch a response from another origin. According to the spec it should work, and the base url should be the response url. If it fails, @wanderview would be interested in adding that failing to the spec.

mfalken commented 6 years ago

Minutes: https://www.w3.org/2017/11/07-serviceworker-minutes.html