Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#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 the loadQ. These are all of lower priority than the parse method.
  • The parse method is processed off the loadQ
  • Thereafter, the req.idle() evaluates to false and the rest of the onDomReady 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 to evalModuleText(cached) in the syncLoadNls 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 the defQ either via onLoadCallback or with an explicit call to runDefQ.
  • 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.

Additional info:

  • The load of the nls module is due to a call to this.dateLocaleModule.getNames in the buildRendering function of a CalendarLite 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 to evalModuleText(cached) and the population of the defQ.

Change History (4)

comment:1 Changed 4 years ago by bill

I think we'd need an actual test case before changing, although I guess that would be hard if it's a race condition.

The load of the nls module is due to a call to this.dateLocaleModule.getNames in the buildRendering function of a CalendarLite? widget in my page. This only happens in the case where there is a i18n preload

Hmm, now I'm lost. If there's an I18N preload then why is stuff getting loaded again in buildRendering()?

comment:2 Changed 4 years ago by dylan

Owner: changed from Rawld Gill to richardg
Status: newpending

richardg, please see Bill's earlier questions...

comment:3 Changed 4 years ago by trac-o-bot

Resolution: invalid
Status: pendingclosed

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 4 years ago by bill

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).

Note: See TracTickets for help on using tickets.