WICG/pending-beacon

Add dedicated worker beacon

mingyc opened this issue · 6 comments

mingyc commented

https://wicg.github.io/unload-beacon/#issue-fdb03e89

ISSUE 2: Add worker beacons as well?

It doesn't make sense to support all types of workers, but only support dedicated worker. It is because a beacon has to be associated with a browsing context and it must not be shared across different context for privacy reason, so service worker & shared worker don't fit the requirement.

Sora2455 commented

In that case, wouldn't the "browsing context" of the dedicated worker be the last browsing context that had the dedicated worker open?

mingyc commented

Yes. What I mean is to support only dedicated worker. Updated to clarify it.

mingyc commented

Correction to my comment above. There are some concerns around the lifetime of a PendingBeacon P created in a dedicated worker W. Trying to list possible options below:

  1. The same as W's lifetime, meaning that P should be sent out or discarded when W is closed.
    • Easiest to understand and use.
    • But in some cases W can live longer than its parent browsing context (Document, or another DedicatedWorker), which might lead to prviacy issues.
  2. The same as the ancestor Document D (which owns W directly or inderectly via nested dedicated workers)'s lifetime.
    • This means every PendingBeacon P created in W should be attached to D.
    • If W is closed earlier before D is destroyed, it's ok.
    • If W stays active after D is destroyed, anything happens to P must be no-op, and no new PendingBeacon can be created.
      • There might be some undesired contentions happen?
  3. The same as parent browsing context (either a Document or a dedicated worker):
    • If parent is dedicated worker, it does not make sense to attach a PendingBeacon to it.

To me it looks like Option 2 is the one closest to the current PendingBeacon behavior. But in that case, why not just creating PendingBeacon in the Document and waiting for data from worker? Do we really need to allow PendingBeacon in worker?

  • 👀1
fergald commented

If W can still make network requests then it should be able to create a new Beacon and have it send when it is finally destroyed.

mingyc commented

Ok so basically Option 1. In such case, backgroundTimeout should be disallowed as there is no page visibility event.

fergald commented

I'm not sure about that disallowing backgroundTimeout. It can still refer to the ancestor frame. We shouldn't make it hard to push code into a worker unless there's a reason why implementing it would be a lot of work.