Bug 1635348 Comment 17 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

I'm afraid that we are focusing too much on the multi-account-containers "hypothetical issue" (1), my main point (from my original comment on the phabricator revision) was that we should provide a reasonably consistent behavior and prepare to communicate to the addon developers:

- what to expect (e.g. new behaviors around the quota, how the migration works)
- what their extension should do to deal with some possible corner cases they may find themselves 
- how they can double-check that their extensions are going to do the right think (while this is still riding the train) and eventually report issue that we may have missed.

The hypothetical multi-account-containers issue was mainly interesting as a way to think of what the extensions may be doing wrong without even realizing, we can't handle optimally every edge-case for sure, we can't even list and test explicitly all possible edge-cases. 
We should just have a consistent behavior and try to avoid introducing more edge-cases to deal with.

I'm absolutely sure that none of us wants to be going around too many circles, what we want is to assess this as quickly as possible and agree on a consistent behavior (and as simple and clear as possible, because it has to also be communicated to the extensions developers) that can allow us to move this forward .

Let's do that.

-----

(1): I looked to the multi-account-containers code and if I'm not reading it wrong, it looks that [it is using an explicit `deletedIdentityList` key stored in the sync data](https://github.com/mozilla/multi-account-containers/blob/da79841201de588f46dbf48fb2ef60954c9b715e/src/js/background/sync.js#L22), and so losing that key shouldn't be making it to remove all the existing containers, as for all the other extension developers we should still let them aware that storage.sync will be migrating data soon so that they can double-check what may go wrong for them).
I'm afraid that we are focusing too much on the multi-account-containers "hypothetical issue" (1), my main point (from my original comment on the phabricator revision) was that we should provide a reasonably consistent behavior and prepare to communicate to the addon developers:

- what to expect (e.g. new behaviors around the quota, how the migration works)
- what their extension should do to deal with some possible corner cases they may find themselves 
- how they can double-check that their extensions are going to do the right thing (while this is still riding the train) and eventually report issue that we may have missed.

The hypothetical multi-account-containers issue was mainly interesting as a way to think of what the extensions may be doing wrong without even realizing, we can't handle optimally every edge-case for sure, we can't even list and test explicitly all possible edge-cases. 
We should just have a consistent behavior and try to avoid introducing more edge-cases to deal with.

I'm absolutely sure that none of us wants to be going around too many circles, what we want is to assess this as quickly as possible and agree on a consistent behavior (and as simple and clear as possible, because it has to also be communicated to the extensions developers) that can allow us to move this forward .

Let's do that.

-----

(1): I looked to the multi-account-containers code and if I'm not reading it wrong, it looks that [it is using an explicit `deletedIdentityList` key stored in the sync data](https://github.com/mozilla/multi-account-containers/blob/da79841201de588f46dbf48fb2ef60954c9b715e/src/js/background/sync.js#L22), and so losing that key shouldn't be making it to remove all the existing containers, as for all the other extension developers we should still let them aware that storage.sync will be migrating data soon so that they can double-check what may go wrong for them).

Back to Bug 1635348 Comment 17