Open
Bug 1900242
Opened 1 year ago
Updated 1 year ago
Replace ClientHandleOp with use of async return value IPC, or at least stop it from redundantly calling its mRejectCallback
Categories
(Core :: DOM: Service Workers, enhancement)
Core
DOM: Service Workers
Tracking
()
NEW
People
(Reporter: asuth, Unassigned)
Details
In a pernosco trace I noticed ClientHandleOp was always calling either the sequence of [mResolveCallback, mRejectCallback] or [mRejectCallback, mRejectCallback]. This is because we never clear out mRejectCallback and always call it during ActorDestroy. Because the callbacks always just make simple calls into MozPromise this doesn't actually pose a problem, but is definitely slightly weird and a bit confusing/surprising inside a debugger.
Ideally we could convert this to using the async return value mechanism to simplify things while eliminating the extra callback, but there are two slightly complicating factors that make this not an entirely rote mechanical change:
- There is a slight conceptual plumbing change as our NS_FAILED case actually would be a resolved value from IPC, not a rejected value (which would correspond to ActorDestroy without ever having received a value).
- Currently we use a discriminated union for the 4 different payloads. Ideally these would be their own async return value calls to reduce obfuscation, but there's also a bit of machinery related to the
EnsureSource()mechanism and effectively forwarding the requests onward to the ClientSourceParent, so there would be some code duplication or template shenanigans. That said, we do already have some template shenanigans for DoSourceOp.
You need to log in
before you can comment on or make changes to this bug.
Description
•