:perry, did "some of the reasons" go away? Is there something left to do?

The change proposed in the bug description hasn't happened, but I am definitely lacking context on what "some of the reasons" refers to and worker loadgroups in general...

Andrew, do you have some more context here?

(In reply to Jens Stutte [:jstutte] from comment #5)

Andrew, do you have some more context here?

I think this is actionable at this point, with most of the related concerns having been addressed. To comment 0's specific items:

1. Bug 1231211 landed and thanks to parent intercept the load group is very explicitly not involved in interception in any way at this point.
2. Devtools is now getting its information via explicit propagation of the BrowsingContextID through PFetch as introduced by Eden in https://phabricator.services.mozilla.com/D174249 as part of bug 1819570.

In terms of the mechanisms at play:

• We copy the document's load group by default in WorkerPrivate::GetLoadInfo when our parent is a window.
• But if we end up without a load group because the parent wasn't a window or a specific override policy is provided, WorkerPrivate::GetLoadInfo calls OverrideLoadInfoLoadGroup which creates a new LoadGroup. This is what happens for RemoteWorkers which means Sharedworkers and ServiceWorkers.
  • Note that we do specify the OverrideLoadGroup policy for our call to WorkerPrivate::GetLoadInfo in SharedWorker::Constructor but we don't actually use the LoadGroup directly when building RemoteWorkerData.

We could probably try specifying the OverrideLoadGroup policy flag for all cases and see what breaks. There's also just a ton of potential to clean up the WorkerLoadInfo logic which has just accumulated a vast amount of cruft as it's generally been append-only with changes stacking up in a series of hacks.