Odoo Changelog — 2024-11-13

Wednesday, November 13, 2024

1 change · master

Refactoring(1)

Code cleanup and technical improvements

[REF] web_tour: new tour engine

Coremasterweb_tourim_livechattest_websitewebsitewebsite_event_salewebsite_salewebsite_sale_autocompleteMedium

Odoo’s automated website and app tours now wait more reliably for screens to finish updating before taking the next action. This reduces false failures and wrong clicks in tests, helping teams validate business flows with more confidence.

Original PR description

In macro.js, the advance() function calls itself at the end.
The advance() function allows you to search for the trigger of a step and then call the run() function if it exists.

There are 2 possible (parallel) paths to find the trigger of the current macro.js.

Case 1. At the end of advance(), we move on to the next step, we look for the trigger DIRECTLY in the DOM. If we find it, we execute the action on it and move on to the next step.
Case 2. In parallel with case 1, there is a MutationObserver. At any time, if a mutation occurs, we wait for a stable state (debounce 750ms without any mutation) then we look for the trigger in the DOM. When we find it, we execute the action.
Corollary: In case 1. we can find the trigger DIRECTLY and the mutations that occur after (2.) will no longer have an impact.
Consequence: We do not necessarily wait for a stable state of the DOM before looking for the trigger.
Solution: When looking for a trigger, we must let the mutations take place (let the DOM have a stable state) before looking for the trigger.

Question: When do we consider that we do not expect mutations?
If the previous step is "just a check" and there is no interaction with the DOM => We can consider that there is no reason to expect mutations. (Note that this is specific to towers, hence a TourEngine)
This allows among other things to correct scenarios where:
- We wait for a modal to close before looking for an element in the DOM.
- The tower takes a wrong path because it found an element that is not really the one we expected.
i.e. Click on a first we-select, Click on an option which must modify the options of a second we-select, Click on the second we-select (case 1), the options are not available (because we did not wait for the mutations before clicking on the second we-select)

#automated tests#tour engine#reliability

In macro.js, the advance() function calls itself at the end. The advance() function allows you to search for the trigger of a step and then call the run() function if it exists. There are 2 possible (parallel) paths to find the trigger of the current macro.js. Case 1. At the end of advance(), we move on to the next step, we look for the trigger DIRECTLY in the DOM. If we find it, we execute the action on it and move on to the next step. Case 2. In parallel with case 1, there is a MutationObserver. At any time, if a mutation occurs, we wait for a stable state (debounce 750ms without any mutation) then we look for the trigger in the DOM. When we find it, we execute the action. Corollary: In case 1. we can find the trigger DIRECTLY and the mutations that occur after (2.) will no longer have an impact. Consequence: We do not necessarily wait for a stable state of the DOM before looking for the trigger. Solution: When looking for a trigger, we must let the mutations take place (let the DOM have a stable state) before looking for the trigger. Question: When do we consider that we do not expect mutations? If the previous step is "just a check" and there is no interaction with the DOM => We can consider that there is no reason to expect mutations. (Note that this is specific to towers, hence a TourEngine) This allows among other things to correct scenarios where: - We wait for a modal to close before looking for an element in the DOM. - The tower takes a wrong path because it found an element that is not really the one we expected. i.e. Click on a first we-select, Click on an option which must modify the options of a second we-select, Click on the second we-select (case 1), the options are not available (because we did not wait for the mutations before clicking on the second we-select)