#18519 closed defect (invalid)
Potential Loader Error: Not all onDomReady events being processed.
Reported by: | richardg | Owned by: | richardg |
---|---|---|---|
Priority: | undecided | Milestone: | tbd |
Component: | Loader | Version: | 1.10.2 |
Keywords: | Cc: | ||
Blocked By: | Blocking: |
Description
The defQ
is not getting properly cleared and leads to the onDomReady
loadQ
not being fully processed.
I have the following situation:
- I have a number of
onDomReady
listeners which are in theloadQ
. These are all of lower priority than theparse
method. - The
parse
method is processed off theloadQ
- Thereafter, the
req.idle()
evaluates to false and the rest of theonDomReady
listeners do not get processed. - This is because the
defQ
is not empty after the parsing. - I tracked the population of the
defQ
down to the call toevalModuleText(cached)
in thesyncLoadNls
function. (The module in question is a cldr bundle.) - However, it seems that following this population, there is no call to process the
defQ
. - I noticed that in all other cases where the
evalModuleText
is called, there is a subsequent processing of thedefQ
either viaonLoadCallback
or with an explicit call torunDefQ
. - Should there be a similar call in this case?
- I added a call to
runDefQ(0)
to test whether this would work and it did resolve my issue. However I don't have sufficient knowledge to identify the possible side effects of this call.
- I added a call to
Additional info:
- The load of the nls module is due to a call to
this.dateLocaleModule.getNames
in thebuildRendering
function of aCalendarLite
widget in my page. - This only happens in the case where there is a i18n preload which populates the i18n cache with the module in question which then results in the
doLoad
not being run for this module.- As far as I can tell, the result of this is that this module does not get into the dojo loader's
modules
hash map. - This then means that the execution path followed in
syncLoadNls
results in the call toevalModuleText(cached)
and the population of thedefQ
.
- As far as I can tell, the result of this is that this module does not get into the dojo loader's
Change History (4)
comment:1 Changed 6 years ago by
comment:2 Changed 5 years ago by
Owner: | changed from Rawld Gill to richardg |
---|---|
Status: | new → pending |
richardg, please see Bill's earlier questions...
comment:3 Changed 5 years ago by
Resolution: | → invalid |
---|---|
Status: | pending → closed |
Because we get so many tickets, we often need to return them to the initial reporter for more information. If that person does not reply within 14 days, the ticket will automatically be closed, and that has happened in this case. If you still are interested in pursuing this issue, feel free to add a comment with the requested information and we will be happy to reopen the ticket if it is still valid. Thanks!
comment:4 Changed 5 years ago by
From the description it does sound like there's a bug, and that richardg found the right fix. Too bad we don't have a test case to confirm. Maybe it only triggers when you have a language setting other than en-us, and it's downloading multiple message files (ex: nls/de/common.js and then nls/common.js).
I think we'd need an actual test case before changing, although I guess that would be hard if it's a race condition.
Hmm, now I'm lost. If there's an I18N preload then why is stuff getting loaded again in buildRendering()?