Investigate ways to ensure remote tabs push gets sent before browser closes
Categories
(Firefox :: Sync, task, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox130 | --- | fixed |
People
(Reporter: skhamis, Assigned: markh)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
Close remote tab commands will be on a timer before we actually send the push. This nets us two main benefits:
- We can bulk the commands if they happen close together
- We can allow the user to undo for a short time before we actually send the command
However, there is an edge case where the user could be closing tabs and then immediately close Firefox -- thus resulting in the pushes never actually getting sent. While this is very edge-casey we should catch the browser as it's closing and try to send off our pushes immediately.
|
Reporter | |
Updated•4 months ago
|
|
Assignee | |
Comment 1•3 months ago
|
||
The default timeout for our requests is 5 minutes and I don't think we customize that for commands. I don't think it's even possible to block shutdown for 5 minutes, and even if it was it would be bad.
At shutdown there are (at least) 2 states which interest us:
- There's already a request in-flight - ie, we've started the request and it will either complete in the timeout period or it will fail as that timeout expires.
- There's no request in flight but there are pending sends (IOW, a timer has been set but is yet to fire)
Note also: "There's already a request in-flight" part highlights another issue - the existing code is quite racey - eg, if we are asked to close another tab while flushQueue has started but is not yet complete things will probably go wrong (eg, we will try and clear an already running timer) We should probably fix this at the same time.
|
|
Assignee | |
Comment 2•3 months ago
|
||
|
||
Updated•3 months ago
|
|
||
Comment 4•2 months ago
|
||
| bugherder | ||
Description
•