#16389 closed defect (fixed)
domReady() method doesn't handle recursive or concurrent calls well
Reported by: | bill | Owned by: | bill |
---|---|---|---|
Priority: | undecided | Milestone: | 1.9 |
Component: | Core | Version: | 1.8.1 |
Keywords: | Cc: | ||
Blocked By: | Blocking: |
Description
dojo/ready will detect if it's called recursively, and then queue the new callback to execute after the current callback finishes. However, domReady() doesn't do this. It's also an issue if domReady() is called from two places concurrently.
Note that this ticket is referring to dojo/domReady used as a function, rather than as a plugin.
This is the main cause of the problem listed in #16386 but I figured it deserved it's own ticket.
Change History (6)
comment:1 Changed 8 years ago by
Milestone: | tbd → 1.9 |
---|---|
Owner: | set to bill |
Status: | new → assigned |
comment:2 Changed 8 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
comment:3 Changed 8 years ago by
Resolution: | fixed |
---|---|
Status: | closed → reopened |
Argh, that broke dojo/tests/parrser/parseOnLoadDeclarativeRequire.html.
comment:4 Changed 8 years ago by
Another good test is dijit/tests/_BidiSupport/layout/AccordionContainer.html. The ready() call inside of dojo/parser.js triggers the parser to auto-load some modules, indirectly including _CssStateMixin, and then _CssStateMixin calls domReady().
The second time AccordionContainer.html is run, without clearing the cache, all of this happens synchronously, which uncovered another bug on IE8 where the callback in the domReady() call in _CssStateMixin wasn't getting run.
In [30057]: