Status?

[marcoscaceres]

Hi folks, what's the status on this work? Enough interest for the Service Worker WG is willing to take it?

[jakearchibald]

Yeah, that's my goal, and there's interest from other vendors.

…

On Tue, 9 Jun 2020, 07:13 Marcos Cáceres, ***@***.***> wrote: Hi folks, what's the status on this work? Enough interest for the Service Worker WG is willing to take it? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#152>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAW3GV2L6OB2FRBDOLYSNLRVXHHDANCNFSM4NZCSTDQ> .

[marcoscaceres]

Ok, that's great to hear! @wicg/Chairs happy to help whenever you want to migrate this over.

[hcientist]

In looking at https://wicg.github.io/background-fetch/ and this repo, I can't tell what the status is in terms of adoption in the <governance w3c term?> or in browsers' experimentation. Is this proposal just too early to track such a thing or is there a way i can understand where it sits in the process of becoming part of a standard? Thanks in advance for educating me and your work anticipating this years ahead of my needs 🙌

[hcientist]

Looks like maybe this table can help me know whether I can expect to play with this in particular browsers https://developer.mozilla.org/en-US/docs/Web/API/Background_Fetch_API#browser_compatibility

[marcoscaceres]

Asked for a standards position from WebKit and poked Mozilla again. Will try to get some status on the WebKit side, as it looks like some code landed in WebKit recently.

@jakearchibald, how are things looking from your perspective?

[jakearchibald]

Chrome is currently looking for a new owner for the implementation for this feature, but it seems to be taking a while and I'm struggling to get a response. Hopefully they'll provide an update here soon.

[inexorabletash]

Hey folks! As @jakearchibald mentions we're still discussing ownership on the Chrome side of things. As always, too many things competing for attention. In the meantime though, let me quote part of a quick internal investigation one of our team members did to help estimate the scope of work on our side, focusing on WPT status.

WPT testing status (and spec)

https://wpt.fyi/results/background-fetch?label=experimental&label=master&aligned makes things look worse than they really are I think. The majority of failing tests there are passing when run in chromium’s test runner using content shell. Not sure what the difference is between how WPT runs tests vs how Chromium runs test, but this might just be a matter of fixing some WebDriver functionality or similar.

There are however a couple of tests (primarily those added recently by WebKit) that do reflect cases where the implementation and spec diverge (the tests match the spec, and presumably the WebKit implementation). The major divergence here is around when certain checks for fetches being done should happen. Per spec and tests things like CSP checks should not cause the BackgroundFetchManager.fetch call to reject. Rather it should resolve with a valid BackgroundFetchRegistration, while trying to get the results from that will fail (the spec is a bit unclear actually how these failures should be surfaced, but at least is clear that the original fetch call shouldn’t reject). See #169 Probably aligning with spec/webkit here makes the most sense? This is another area where these checks are duplicated between regular fetching code and the background fetch implementation. I’m not sure if there is an easy way to share more implementation here though, but it seems that at least changing when/where these checks happen shouldn’t be much more complicated than moving the existing code around a bit.

I'll caution that "Probably aligning with spec/webkit here makes the most sense?" does not represent a firm consensus on our side - we simply haven't done more than a cursory look here. Not saying that's not where we'll land, but it shouldn't be taken as a strong signal.