Thursday, August 27, 2026
3 changes · 18.0
Enhancements to existing features
The mail test suite now re-checks certain pending conditions more frequently instead of waiting up to 10 seconds. This reduces unnecessary waiting in automated testing, helping developers get feedback faster without changing user-facing behavior.
Original PR description
Before this commit, a contains that does not match right away runs again only when its MutationObserver fires, and once more at the 10 seconds timeout. The problem is that the observer reports neither a text node updated in place nor an input value or checked property, so a check waiting for one of those sleeps 10 seconds and then passes: "Delete starred message decrements starred counter once" spends 10.2s of the 183s @mail suite waiting for a counter to go from "Starred3" to "Starred2". This commit turns that single timeout into a 500ms tick up to the same deadline, so that such a check costs 500ms. The tick uses the unmocked timer to stay out of the timer graph a test drives with runAllTimers, and only 32 of the suite's 4239 contains calls stay pending long enough to tick once.
The web test runner now avoids unnecessary memory cleanup pauses unless memory use is actually high. This reduces wasted time during automated testing while keeping the existing safety behavior for browsers that cannot report memory usage.
Original PR description
Before this commit, the unit test runner pauses for a major garbage collection after every test file, since __gcAndLogMemory collects whenever window.gc exists and browser_js always passes --js-flags=--expose-gc. The problem is that the heap it protects stays at 183MB of a 4192MB limit, so those collections reclaim nothing: the 84 of an @mail run cost 8.8s of its 183s, and the whole suite has 1268 test files. This commit turns the unconditional collection into one that runs only past half the limit, so that a run pays for it when the heap really grows. A browser without performance.memory keeps collecting after every file.
The live chat settings now explain that automatic chat popups only open on larger screens. This helps teams understand why mobile visitors see the chat button instead of an automatically opened chat window during testing or rollout.
Original PR description
The 'Open automatically' action only triggers the auto popup on larger screens (`ui.isSmall` is checked in `AutopopupService. allowAutoPopup`). On mobile/small viewports, only the chat button is shown and the visitor must tap it manually. The existing help text does not mention this, which could lead to confusion when the auto popup does not trigger during testing on mobile. Update the field's help text to explicitly state that automatic opening is limited to larger screens. opw-6459279 Forward-Port-Of: odoo/odoo#284785