Opened 10 years ago

Closed 10 years ago

#15090 closed defect (duplicate)

loader fails to properly load some nls resources, require() returns '3' in their slot

Reported by: Nick Fenwick Owned by: Nick Fenwick
Priority: undecided Milestone: tbd
Component: General Version: 1.7.2
Keywords: Cc:
Blocked By: Blocking:


I've banged my head against this a fair bit but I'm coming at this loader code cold and it's left me a little confused. My situation is that the month name of March is being returned from dojo/date/locale/format() as the string '3'.

This seems to be because the loader, when asked to load dojo/cldr/nls/gregorian.js, is properly deciding to load the 'en' and 'en_gb' modules also (which have the "March" month name in them) but they are not properly loaded, only the base dojo/cldr/nls/gregorian.js bundle is, and it just has a "3" for the month names.

I took this screenshot while debugging the loader:

The slots being returned in the require() callback are 3, which is the 'nonmodule' constant defined in dojo.js. This is because the nonModuleProps object is being mixed over the top of the module definition, forcing its result to be 3, along with a few other variables.

I looked into the code in some detail but I hope this will jump out as a more obvious higher level situation to someone more familiar with the code.

I'll attach a test case. A single "mydijits" module outside of the tree, whose sole purpose is to build dojox/widget/Calendar (and thus the gregorian bundle) into mydijits/Dep. index.html requires mydijits/Dep and then prints the value of the month name, which comes out as '3'. You can see the network activity only loads mydijits/nls/Deps_en-gb.js (in my case) which contains the correct month names but fails to load properly.

If you change the Calendar dependency in mydijits/Dep.js to something innocuous like dijit/form/TextBox, the month name is resolve correctly, because then the gregorian.js file is read from dojostaging/dojo/cldr/.... and not from the external module.

To use the attached test case:

  1. extract it to /somedir
  2. extract dojo-release-1.7.2-src to /somedir also
  3. cd /somedir/dojo-release-1.7.2-src/util/buildscripts
  4. ./ -r -p ../../../test
  5. open /somedir/index.html in web browser, so it loads the /somedir/dojostaging built dojo from step 4/

Attachments (1)

nlsproblem.tar (10.0 KB) - added by Nick Fenwick 10 years ago.
Simple test case for build and test of problem.

Download all attachments as: .zip

Change History (8)

Changed 10 years ago by Nick Fenwick

Attachment: nlsproblem.tar added

Simple test case for build and test of problem.

comment:1 Changed 10 years ago by ben hockey

Owner: set to Nick Fenwick
Status: newpending

i've seen the exact same thing you're talking about and there have been a couple of nls related fixes recently. have you tried against trunk? i think #14989 is the same issue and it has been fixed in trunk.

can you try trunk?

comment:2 Changed 10 years ago by Nick Fenwick

Status: pendingnew

I've tried trunk and get different and equally worrying results.

By the way, I've noticed that only dojo/cldr/nls/en/gregorian and dojo/cldr/nls/en-gb/gregorian are baked into mydijits/nls/Deps_en-gb.js. Is that normal? I thought dojo/cldr/nls/gregorian, i.e. the base bundle, would be baked in too. This explains partially what I saw when debugging through the loader.. it would inspect the en and en-gb bundles and decide they were non-amd and discard them as 'nonmodule', or something along those lines. Is the root problem that not all gregorian bundles are coming from the same location, i.e. one is from dojo/cldr/nls, and two are from mydijits?

Testing on trunk I see it fetching first dojo/cldr/nls/gregorian.js, and then my Deps_en-gb.js file.. and it still contains "3" for the gregorian long month name for March.

    7 requests
      /nlsproblem  31ms12ms
      /nlsproblem/dojostaging/dojo  5ms9ms
      /nlsproblem/dojostaging/dojo  2ms3ms
      /nlsproblem/dojostaging/mydijits  2ms3ms
      /nlsproblem/dojostaging/dojo/cldr/nls  2ms1ms
      /nlsproblem/dojostaging/mydijits/nls  6ms2ms
      /nlsproblem/dojostaging/dojo  3ms0ms

I thought that perhaps my original index.html was naive, requiring the base bundle dojo/cldr/nls/gregorian and expecting that to have the locale specific strings in it .. I really don't know what's correct .. so, on the Console of my index.html after running the latest build against trunk:

  > require(["dojo/i18n!dojo/cldr/nls/en/gregorian"], function(i18n) {
      console.log(i18n['months-format-wide'][2] )

I would expect that "3" to be "March". Inspecting the i18n variable in that example shows they're clearly just the plain dojo/cldr/nls/gregorian.js values i.e. no locale specific stuff at all.

Commenting out the dojox/widget/Calendar from Deps.js, i.e. not baking any locale bundles into my build, 'fixes' the printout, because all gregorian.js resources are fetched from dojo core, as in my original report.

comment:3 Changed 10 years ago by chrisacky

Here is a screenshot to show some of the problems I am having with the same issue also.

I don't even know what the "4 28 3 2012" formatting is. The "4" doesn't represent anything?

comment:4 Changed 10 years ago by Nick Fenwick

I just re-tested, fetched latest SVN trunk (revision 28349) and cleaned by build dir, re-built, cleared browser cache, refreshed, and got same behaviour: March appears to be: 3

However, I then sat there hitting Refresh a few times, and it jumps between 3 and March. There seems to be a race condition in the loader that means most of the time it fails but sometimes works. I'm running on an extremely fast i7 machine with SSD hard drive, so perhaps this behaviour would be different on other machines.

Would really like to hear a core Dojo guy confirm this bug :) And/or, get this ticket assigned to someone more in the know.

comment:5 Changed 10 years ago by Nick Fenwick

By the way, I also added a package.json and package.profile.js to my 'mydijits' module to declare everything to be 'AMD', but it didn't seem to change much. I get the intermittent behaviour with or without those files.

comment:6 Changed 10 years ago by Nick Fenwick

I just discovered a major screwup on my part, I left the old dojo-release-1.7.2-src location in my test.profile.js build profile, so although I was running the build from within my trunk checkout, it was not using the trunk copies of dojo. This is why my tests against trunk were not working.

Fixed my build profile, ran again, it works fine. This ticket can be closed, probably as a dup of #14989 since this was a valid bug but has been fixed by patches on another ticket.

comment:7 Changed 10 years ago by ben hockey

Resolution: duplicate
Status: newclosed

Duplicate of #14989.
oh... that's awesome. i was going out of my mind trying to figure out how it could be failing and it was sounding more and more like #14989

Note: See TracTickets for help on using tickets.