diff options
| author | qsm-odoo <qsm@odoo.com> | 2017-08-10 11:36:49 +0200 |
|---|---|---|
| committer | qsm-odoo <qsm@odoo.com> | 2017-08-10 15:22:20 +0200 |
| commit | fdc8bc171108c6d97b9f73ad9dc5ebeea1860d56 (patch) | |
| tree | 56bd0edf4e8f0cbfd097932c6f05c9472d6bdbb6 /doc/_extensions | |
| parent | 6d3acf6d4a368f0f90f34868b9ce79210817aa9f (diff) | |
[FIX] web: resolve `ajax.loadXML` deferred at the proper time
There was a problem with the new `ajax.loadXML` implementation
introduced with 417a664f16abc67bee40a0067103f9cf2c412aed
Indeed the following case was buggy:
```
ajax.loadXML('URL1', qweb);
ajax.loadXML().then(function () {
ajax.loadXML('URL2', qweb);
});
```
With this code, 'URL2' is scheduled to be loaded when 'URL1' is fully
loaded. The problem is that the deferred returned by the call to
`ajax.loadXML` without argument was resolved before the internal
`isLoading` variable was reset to `false`. So, the loading of 'URL2'
was indeed scheduled when 'URL1' was fully loaded but its loading
never started because the `ajax.loadXML` loading loop was still marked
as running (so it was not started again as it should have been).
Diffstat (limited to 'doc/_extensions')
0 files changed, 0 insertions, 0 deletions
