should ServiceWorkerContainer.getRegistrations() check the uninstalling flag

[wanderview]

Currently we set the uninstalling flag when an unregister job runs but we can't remove the registration yet. For example, its still controlling a client. This flag is then used to hide the registration when someone calls navigator.serviceWorker.getRegistration().

We don't, however, check the uninstalling flag in navigator.serviceWorker.getRegistrations(). So an uninstalling registration will show up there.

Is this intentional? It seems very confusing to me that the registration for your scope might show up in getRegistrations(), but not getRegistration(). I would expect them to have similar logic.

Note, an uninstalling registration will still be exposed via self.registration in the service worker thread itself.

[wanderview]

I'm going to implement hiding uninstalling registrations for now.

[wanderview]

Jake gave me a vague head nod in IRC, so I'm going to land this in gecko with a new wpt test case.

[jungkees]

I agree to add checking uninstalling flag to getRegistrations(). To me, setting the uninstalling flag of a registration means it won't be valid but just continue to control the existing clients until they unload. So, I think self.registration should return undefined for consistency. WDYT?

One occasion we might have to consider is when the uninstalling registration is being reclaimed by re-register() before being cleared up. In this case, getRegistration(), getRegistrations() and self.registration in the same global will start to return the registration again. I think it seems reasonable. Does anyone have any concern about this behavior?

[wanderview]

I'm not sure its worth clearing self.registration. Code can always keep one of these DOM objects alive just by doing self.myReg = self.registration.

We could expose a self.registration.uninstalling flag, though.

[jungkees]

I'm not sure its worth clearing self.registration. Code can always keep one of these DOM objects alive just by doing self.myReg = self.registration.

Yeah, clearing self.registration seems not necessary as you mentioned though this is also true for getRegistration(url) in a document where the subsequent calls to the same method after the uninstalling flag is set won't return the registration. But the latter case is more natural as we don't want to match a SW of the uninstalling registration to a new client.

Let's keep the current behavior for self.registration.

We could expose a self.registration.uninstalling flag, though.

I think this is not necessary until we get some requirements from devs.

[rubys]

I think this is not necessary until we get some requirements from devs.

I guess I qualify as a dev. I posted the following recently: https://lists.w3.org/Archives/Public/public-webapps/2016JulSep/0016.html - see point #5.

I would like EITHER navigator.serviceWorker.getRegistrations() to not return registrations that are in the process of being uninstalled, OR for there be a way to check if a registration that was returned is in the process of being uninstalled.

Fair enough?

[jungkees]

Sorry to have missed the point 5 there. Thanks for reminding me. Indeed, the OP is exactly around that requirement, and I agree to change it as suggested: ".getRegistrations() to not return registrations that are in the process of being uninstalled."

I don't have a strong feeling about adding self.registration.uninstalling though. If it is the case it has a good use case even after changing the getRegistrations() behavior as above, please let me know.

[jungkees]

Let's talk about self.registration.uninstalling in a new thread if it is required. Thanks.

[jungkees]

/cc @wanderview @mattto @nhiroki @aliams

[wanderview]

LGTM. I'm ambivalent to the uninstalling flag.

[aliams]

I agree to change it as suggested: ".getRegistrations() to not return registrations that are in the process of being uninstalled."

@jungkees, that sounds good to me.

Let's talk about self.registration.uninstalling in a new thread if it is required.

I'm not sure I understand the use case of exposing an uninstalling flag via self.registration.uninstalling. Can you clarify please?

[jungkees]

I'm not sure I understand the use case of exposing an uninstalling flag via self.registration.uninstalling.

I haven't come across any use case yet. I guess @wanderview might have thought it would help in case we need some way to prevent further operations on a registration when it's being uninstalled. However, I don't see any issue with the current behavior: when called on an uninstalling registration, registration.update() rejects, and registration.unregister() resolves with true if it's still waiting to be cleared or resolves with false if it's already cleared, which seem reasonable to me.

[wanderview]

One use case would be short circuiting logic if you see self.registration.uninstalling is true. For example, you might not perform some expensive operation since you know the result will be thrown away soon.

But in general I don't think we really need this yet.