Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#14459 closed defect (fixed)

[regression] Cannot load a local module alongside xd dojo using legacy APIs

Reported by: Kenneth G. Franqueiro Owned by: Rawld Gill
Priority: blocker Milestone: 1.7.2
Component: Loader Version: 1.7.0
Keywords: Cc:
Blocked By: Blocking:


I've been trying to arrive at a workable solution to suggest on the reference-guide section regarding CDN usage with local modules as well as the existing tutorial at

I've attempted the following, loosely based on the demo on that cdn tutorial...

Given this:

    <script data-dojo-config="
          baseUrl: './',
          modulePaths: {custom: 'custom'}"

I have changed it to this:

    <script data-dojo-config="
          packages: [ { name: 'custom', location: location.pathname.replace(/\/[^/]+$/, '/custom') } ]"

This is the same kind of formula applied here, which seems to work in async: true cases. Unfortunately I'm not having so much luck when attempting to make it work with legacy code.

With the change mentioned above, I get a dojo.declare mixin error, because the code in the custom module attempts to declare an extension to dijit.Dialog, but while dijit is defined, dijit.Dialog is not. It would seem as though this module is getting its dojo.require calls run in async mode, even though it is on the same domain. For what it's worth though, I don't see a script tag generated for it as with the other xd-loaded modules.

I'm attaching a zip with test.html and custom/Hello.js, which should be enough to reproduce this, although you'll have to finagle the path to a cross-domain location of Dojo 1.7.1 RC2.

I'm assigning this as milestone 1.7.1 initially. While I'd love to see it fixed for 1.7.1, let me know how much effort you think it'd involve first; I don't mean to be a slave-driver. (If it ends up being my own PEBKAC and there's a way around it, that'd be great too.)

Attachments (2) (1.2 KB) - added by Kenneth G. Franqueiro 10 years ago.
app.php (708 bytes) - added by Slavon 8 years ago.

Download all attachments as: .zip

Change History (11)

Changed 10 years ago by Kenneth G. Franqueiro

Attachment: added

comment:1 Changed 10 years ago by Rawld Gill

This error can be reduced as follows:

  1. Build dojo using the standard profile.
  2. Put the following two files in the dtk directory:


      data-dojo-config="paths:{m: '/dev/dtk/m'}"	


var test = dojo.declare([dijit.Dialog], {});
  1. Load t.html using localhost to simulate loading dojo xd (something like http://localhost/dtk/t.html)

You'll see that dijit.Dialog is not defined when it's referenced on the second line of m.js. This is because m.js is local and therefore loaded synchronously and then evaluated. The loader doesn't understand it's needs a cross-domain module until it starts evaluating m.js, but by then it's too late to stop evaluation to prevent the error.

comment:2 Changed 10 years ago by Kenneth G. Franqueiro

Version: 1.7.1rc11.7.0

comment:3 Changed 10 years ago by Rawld Gill

Status: newassigned

comment:4 Changed 10 years ago by Colin Snover

Priority: highblocker

Bumping priority due to surprisingly high complaint volume.

comment:5 Changed 10 years ago by Rawld Gill

Resolution: fixed
Status: assignedclosed

In [27763]:

fixes #14459; update some tests; see ticket; !strict

comment:6 Changed 10 years ago by Colin Snover

Resolution: fixed
Status: closedreopened

Confirmed fix works on trunk; reopening to make sure this gets backported to 1.7 branch. Thanks Rawld for your hard work getting this taken care of.

comment:7 Changed 10 years ago by Rawld Gill

version 1.6- seemed to have the ability to switch into and out of xdomain mode when dojo was loaded xdomain. This is indicated by the behavior of the switch dojo._isXDomain and the configuration variable dojo.config.useXDomain in 1.6.x.

The v1.7 loader implements this behavior. However...

  • the 1.6- loader, in fact, never implemented/tested/documented/employed this behavior fully as evidenced by the switch useXDomain being undocumented and always hard set to true by the following code that is inserted into a xdomain build in v1.6-
    if (typeof dojo.config["useXDomain"] == "undefined") {
    	dojo.config.useXDomain = true;

In fact, hard setting this is required to make the use case above and the tutorial work and great care must be taken if the switch useXDomain is to be set other than true.

The repair committed in [27763] causes the default behavior of the 1.7 loader as built for a CDN to behave like the 1.6 loader in that *all* resources will be loaded in xdomain mode.

  1. The has feature test "dojo-cdn" has been added to properly resolve the xd path; this replaces the 1.6 build switch xdDojoPath which does not exist in 1.7. The loader has been modified to automatically set the package location property for dojo, dijit, and dojox iff the has feature dojo-cdn is truthy.
  1. a cdn profile has been added at utils/buildscripts/profiles/cdn.profile.js which sets async to "legacyAsycn" (which permanently puts the loader is xdomain mode) as well as sets the has feature "dojo-cdn" to truthy.
  1. The CDN build shell script has been augmented to include the cdn profile *as well as* the standard profile.


  • The procedure for building dojo for CDN distribution has not changed...use util/buildscripts/
  • a user config can still override all of this default configuration.

comment:8 Changed 10 years ago by Rawld Gill

Resolution: fixed
Status: reopenedclosed

In [27781]:

backport [27773]; fixes #14459; !strict

comment:9 Changed 10 years ago by Rawld Gill

In [27782]:

fixed whitespace change improperly committed in [27781]; refs #14459; !strict

Changed 8 years ago by Slavon

Attachment: app.php added
Note: See TracTickets for help on using tickets.