diff options
| author | Alexandre Kühn <aku@odoo.com> | 2019-12-19 13:26:44 +0000 |
|---|---|---|
| committer | Alexandre Kühn <aku@odoo.com> | 2019-12-20 09:53:26 +0000 |
| commit | 141b34f152f36d970d4ff78abe53f563555a8e69 (patch) | |
| tree | 91c263df12a5b4cd0f5dc089fb608599cd570390 /addons/web/static/src/js/views/basic/basic_view.js | |
| parent | e4e838a0199b163658f943f526196e55a3d8a167 (diff) | |
[FIX] web: tests: nextTick awaits render with requestAnimationFrame
Revision on [1].
Commit above made changes to test helper `nextTick()`, so that it
waits for `window.nextAnimationFrame()` (shorten, 'rAF'). This was
useful to wait for OWL rendering, since OWL renders on next animation
frame.
From a theoretical standpoint, the helper should wait at least as
much time as before, as it adds either no slowdown (rAF is readily
available), or a few milliseconds wait (rAF waits for next available
animation frame).
However, some old tests show non-deterministic behaviours, resulting
to crashes [2]. It suggested, for some reasons, that `nextTick()` did
not wait long enough for re-render... Which is surprising considering
explanation above!
Some of these tests have been fixed, assuming it was caused by un-
guaranteed order of successive `setTimeout(0)` [3]. Unfortunately,
this does not explain why it never crashed before the change on
`nextTick()`...
After investigation, we think that this behaviour comes from rAFs
having their own task queue, which no longer guarantees that queued
tasks happen after queued micro-tasks:
When the requested next animation frame is readily available, the
callback of `requestAnimationFrame()` is immediately called and waits
for `setTimeout(0)`. The `setTimeout(0)` await is resolved before any
other queued async micro-tasks, so that `nextTick()` is resolved
sooner than expected. This would explain how `nextTick()` does not
wait long enough for rendering from the loads of resolved Promises,
even though there is a promise resolution after `setTimeout(0)`.
This commit fixes the issue by moving the await `setTimeout(0)`
before the rAF call, so that it correctly waits render from chain of
resolved promises (since the `setTimeout(0)` is awaited in the same
main task queue).
[1] https://github.com/odoo/odoo/commit/b0941d19a07b08fabc64a284b58e57edc46203dd
[2] http://runbot.odoo.com/runbot/build/771505 and http://runbot.odoo.com/runbot/build/752855
[3] https://github.com/odoo/odoo/commit/6cbfdbce2d0f1b567b6a6d6f637fe2a476980acc
closes odoo/odoo#42123
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
Diffstat (limited to 'addons/web/static/src/js/views/basic/basic_view.js')
0 files changed, 0 insertions, 0 deletions
