Opened 9 years ago

Closed 7 years ago

#11230 closed defect (fixed)

Dojo fails to detect successfully loaded resources (chrome-extension)

Reported by: yveskurz Owned by:
Priority: low Milestone: 1.7
Component: Core Version: 1.4.3
Keywords: Cc:
Blocked By: Blocking:

Description

I'm writing a Chrome Web App which is using an embedded version of Dojo. This currently does not work as dojo.js fails to load with the following error:

Uncaught Error: Could not load 'dojo._base.lang'; last tried './_base/lang.js'

The cause for this is that xhr returns status code 0 on a successfully loaded resources with the consequence that dojo._isDocumentOk() (hostenv_browser.js) returns false.

The problem can be easily fixed by adding "chrome-extension:" to the list of stange behaving protocols.

I have no idea if that is the correct fix but changing the function as follows allows me to use Dojo in my Chrome Web App.

d._isDocumentOk = function(http){
   var stat = http.status || 0,
       lp = location.protocol;
       return (stat >= 200 && stat < 300) || 	// Boolean
	  stat == 304 ||                        // allow any 2XX 
          stat == 1223 || 			//  cache
          (!stat && (lp == "file:" || lp == "chrome:" || lp == "app:" || lp == "chrome-extension:"));
}

Change History (15)

comment:1 Changed 9 years ago by James Burke

Resolution: fixed
Status: newclosed

(In [22260]) Fixes #11230, allow dojo loader to work in chrome extension.

comment:2 Changed 9 years ago by James Burke

Milestone: tbd1.5

comment:3 Changed 9 years ago by Mark Wubben

James, it strikes me that you're testing location.protocol, which is the protocol for the host environment resource (i.e. chrome-extension://uniqueid/background.html) rather than the protocol of the requested URL.

comment:5 Changed 9 years ago by James Burke

markwubben: yes, this is by design, the 0 status should depend on the page/host environment resource. I am tempted to just treat a non-existent status as just OK though and remove all those checks. I am not sure though if there is a case where status is legitimately 0 and indicates an error though.

dante: I read that comment as saying they were having a general problem in Chrome on OSX even before this change and asking if this change would fix their issue. I left a comment for them and hopefully we can get clarification.

comment:6 Changed 9 years ago by Adam Peller

(In [22544]) Test for \!stat to include various other local loading cases, like appcache hits in Safari, and save a few bytes. Refs #11230

comment:7 Changed 9 years ago by Adam Peller

(In [22545]) Remove unneeded local var after change in [22544]. Refs #11230

comment:8 Changed 8 years ago by Adam Peller

(In [24489]) Rollback r22544 check for http response status 0. Refs #12516, #11230

comment:9 Changed 8 years ago by Adam Peller

Milestone: 1.5tbd
Resolution: fixed
Status: closedreopened

comment:10 Changed 8 years ago by Adam Peller

Resolution: fixed
Status: reopenedclosed

(In [24490]) Rollback r22544 check for http response status 0 on 1.6 branch. Fixes #11230

comment:11 Changed 8 years ago by Adam Peller

Milestone: tbd1.6.1

comment:12 Changed 8 years ago by Adam Peller

Milestone: 1.6.1tbd
Resolution: fixed
Status: closedreopened

oops. meant to close #12516. leave this open.

comment:13 Changed 8 years ago by Chris Mitchell

Owner: anonymous deleted

comment:14 Changed 7 years ago by ben hockey

Keywords: needsreview added
Priority: highlow

comment:15 Changed 7 years ago by bill

Keywords: needsreview removed
Milestone: tbd1.7
Resolution: fixed
Status: reopenedclosed

This ticket doesn't really make sense anymore, because in the AMD world we load via <script> tags not via XHR. So I'm going to close it as fixed w/the introduction of AMD.

Note: See TracTickets for help on using tickets.