During testing of password change I observed spurious increments of my storage revision in local storage not explained by the log of the tab I was testing. Turned out they were coming from an idle background tab (pond-control) with the scenario below. I don't have an immediate idea to fix this cleanly, but will instead focus on #1342 to reduce the risk of data loss. This issue is to capture my understanding of the problem for later.
Scenario:
- Password change from active tab broadcasts to background tabs.
- Background tab receives broadcast, responds by loading
self and encryptionKey from local storage into appState.
- Changing appState triggers sync.
- Sync checks the hash of storage (which includes
self), finds it has changed, so it uploads.
Note that being offscreen suppresses the periodic triggers for download + feeds, but doesn't suppress sync in general. When app state changes, and sync thinks an upload is needed, it'll do so in the background.
This extra upload uses the correct new key, so it's not blatantly broken. However it currently has a good chance of clobbering recent changes, since the background tabs in-memory state is likely to be older than the active tab's. Once merging is implemented (see #1342) it'll trigger and reduce this risk like others.
Fixing this in general is part of the broad class of issues of making sync coordinate through local storage between multiple tabs. Right now, multiple tabs interact primarily via the server (with special-case exceptions like password change). Fixing that general issue is a big work item for the future.
More targeted tweaks for this behavior are possible, but questionable:
- Trigger an extra download on the background tab. This at least makes the clobbering more likely to be in the non-dangerous direction, and/or makes the merge happen faster once merge is supported.
- Load PCDs and subscriptions directly from local storage in the background tab. This is questionable because while we know the foreground tab just uploaded, we don't know it how recently it saved PCDs. It's likely to be newer, but this could clobber in the other direction if the background tab failed to upload some prior changes. In general this tweak would break the mental model of tabs syncing only via the server.
During testing of password change I observed spurious increments of my storage revision in local storage not explained by the log of the tab I was testing. Turned out they were coming from an idle background tab (pond-control) with the scenario below. I don't have an immediate idea to fix this cleanly, but will instead focus on #1342 to reduce the risk of data loss. This issue is to capture my understanding of the problem for later.
Scenario:
selfandencryptionKeyfrom local storage into appState.self), finds it has changed, so it uploads.Note that being offscreen suppresses the periodic triggers for download + feeds, but doesn't suppress sync in general. When app state changes, and sync thinks an upload is needed, it'll do so in the background.
This extra upload uses the correct new key, so it's not blatantly broken. However it currently has a good chance of clobbering recent changes, since the background tabs in-memory state is likely to be older than the active tab's. Once merging is implemented (see #1342) it'll trigger and reduce this risk like others.
Fixing this in general is part of the broad class of issues of making sync coordinate through local storage between multiple tabs. Right now, multiple tabs interact primarily via the server (with special-case exceptions like password change). Fixing that general issue is a big work item for the future.
More targeted tweaks for this behavior are possible, but questionable: