-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[FIX] bus, mail: correctly synchronize document chat windows
Before this commit, there could be an infinite loop when changing the chat window state of a document chat window. This is caused when mutiple tabs overwrite the chat window state with a different value everytime, resulting to an infinite loop. Accross multiple tabs, `setItem` and `onStorage` are not synchronous. That's why tabs should communicate through local storage events instead of actual value in the local storage. To illustrate the issue, suppose there are 2 tabs (T1 and T2) with one document chat windows (C) and the following user interactions: - T1 and T2 both have C open - on T1, user folds C - on T2, user folds C Now let's add an example of local storage (LS) logics that could apply from above example: - T1 and T2 both have C open - on T1, user folds C [1] T1 writes 'C folded' in LS - on T2, user folds C [2] T2 writes 'C folded' in LS [3] T2 detects 'C folded' in LS (from [1]) => T2 writes 'C folded' in LS [4] T1 detects 'C folded' in LS (from [2]) => T1 writes 'C folded' in LS [5] T1 detects 'C folded' in LS (from [3]) => T1 writes 'C folded' in LS [6] T2 detects 'C folded' in LS (from [4]) => T2 writes 'C folded' in LS etc... This scenario could have been easily prevented by not writing on local storage when the chat window state has not changed. However, this wouldn't fix this scenario that also introduces an infinite loop: - T1 and T2 both have C open - on T1, user folds C [1] T1 writes 'C folded' in LS - on T2, user folds C [2] T2 writes 'C folded' in LS - on T2, user unfolds C [3] T2 writes 'C unfolded' in LS [4] T2 detects 'C folded' in LS (from [1]) => T2 writes 'C folded' in LS [5] T1 detects 'C unfolded' in LS (from [3]) => T1 writes 'C unfolded' in LS [6] T2 detects 'C unfolded' in LS (from [5]) => T2 writes 'C unfolded' in LS [7] T1 detects 'C folded' in LS (from [4]) => T1 writes 'C folded' in LS [8] T2 detects 'C folded' in LS (from [7]) => T2 writes 'C folded' in LS [9] T1 detects 'C unfolded' in LS (from [6]) => T1 writes 'C folded' in LS etc... This commit fixes the infinite loop issue: - by turning local storage read during cross-tab communication into local storage event read instead. This should prevent race conditions based on read/write operations in local, since their order is not guaranteed accros tabs. - by isolating document chat window state to their own local storage entry. This should prevent a tab from notifying a chat window state that it didn't change, which may also result in an infinite loop. Some tests were adapted from the changes above. Also, some tests did pass thanks to local storage being mocked by a ram storage: the handler `_onStorage` should have been called, but it didn't because it was registered on the actual local storage instead of the ram storage. In order to make tests pass again, the following additional changes were required: - Cross-tab bus service now exports the unique tab ID with `getTabId`. - document thread entries in local storage now track the tab ID, so that self-tab ignore their own local storage writes. Task-Id 2034997 Closes odoo#36177
- Loading branch information
Showing
5 changed files
with
99 additions
and
33 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters