Bugzilla

(In reply to :Gijs (back Thu 12; he/him) from comment #24)
> We could add a shutdown blocker for the indexeddb usage from RemoteSettingsClient.jsm, but that feels odd - is the expectation that all indexeddb consumers do their own shutdown blocking?

To somewhat reiterate the second part of https://bugzilla.mozilla.org/show_bug.cgi?id=1594521#c19:
- System code really should be aware of shutdown.
  - https://phabricator.services.mozilla.com/D53751 in bug 1594521 took care of the remote settings worker's IDB usage around this, I think, but I hadn't quite realized there was still main thread stuff going on with IndexedDB.
  - Enhancement bug 1597693 that was spun off from https://bugzilla.mozilla.org/show_bug.cgi?id=1594521#c12and later comments would address the general problem of the worker global living beyond the point that it's safe for system level JS to be running, but there's not currently any affordance like this for main-thread system JS beyond shutdown blockers that I'm aware of.
  - It might be possible to file an enhancement such that JSM's can be associated with a phase at which point their global/compartment/sandbox/whatever-they-are gets destroyed and causes nsIGlobalObject::DisconnectEventTargetObjects() to be called which could similarly help reduce the effort to be shutdown aware.
- There's definitely an IndexedDB bug, which I think might be bug 1597312 that I filed as a result of that bug discussion, so I'm going to drop the needinfo on Tom.
  - When this is fixed, code trying to use IndexedDB will receive some combination of synchronous and asynchronous errors rather than resulting in weird hangs, but this is likely to really mess up the telemetry statistics for any callers plus any telemetry IndexedDB gathers on error rates, so it's nice for callers to be shutdown aware.

(In reply to :Gijs (back Thu 12; he/him) from comment #24)
> We could add a shutdown blocker for the indexeddb usage from RemoteSettingsClient.jsm, but that feels odd - is the expectation that all indexeddb consumers do their own shutdown blocking?

To somewhat reiterate the second part of https://bugzilla.mozilla.org/show_bug.cgi?id=1594521#c19:
- System code really should be aware of shutdown.
  - https://phabricator.services.mozilla.com/D53751 in bug 1594521 took care of the remote settings worker's IDB usage around this, I think, but I hadn't quite realized there was still main thread stuff going on with IndexedDB.
  - Enhancement bug 1597693 that was spun off from https://bugzilla.mozilla.org/show_bug.cgi?id=1594521#c12 and later comments would address the general problem of the worker global living beyond the point that it's safe for system level JS to be running, but there's not currently any affordance like this for main-thread system JS beyond shutdown blockers that I'm aware of.
  - It might be possible to file an enhancement such that JSM's can be associated with a phase at which point their global/compartment/sandbox/whatever-they-are gets destroyed and causes nsIGlobalObject::DisconnectEventTargetObjects() to be called which could similarly help reduce the effort to be shutdown aware.
- There's definitely an IndexedDB bug, which I think might be bug 1597312 that I filed as a result of that bug discussion, so I'm going to drop the needinfo on Tom.
  - When this is fixed, code trying to use IndexedDB will receive some combination of synchronous and asynchronous errors rather than resulting in weird hangs, but this is likely to really mess up the telemetry statistics for any callers plus any telemetry IndexedDB gathers on error rates, so it's nice for callers to be shutdown aware.