#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.
The two-queue thing turns out not to work in the above case. The order of events is:
- ready.js calls ready() to load the parser
- test file calls ready(1000, ...)
- parser finishes loading calls ready(100, parser.parse)
- test file's ready() callback executes
- (later) parser finishes asynchronous auto-load of widgets
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]: