Opened 13 years ago

Closed 13 years ago

Last modified 12 years ago

#1618 closed defect (invalid)

XHR fails before dojo.js itself loaded

Reported by: liucougar Owned by: James Burke
Priority: high Milestone:
Component: General Version: 0.3
Keywords: Cc:
Blocked By: Blocking:

Description

use this profile to build dojo:

var dependencies = [
        "dojo.widget.Clock"
];

load("getDependencyList.js");

then try to load tests/widget/test_Clock.html, a fatal error is reported: FATAL exception raised: Could not load 'dojo.gfx.svg'; last tried 'package.js'

this is due to the problem that while dojo.js is loading, any XHR fails

Attachments (1)

1618.patch (1.1 KB) - added by liucougar 13 years ago.

Download all attachments as: .zip

Change History (12)

comment:1 Changed 13 years ago by James Burke

I think a possible fix would be to change the result of dojo.hostenv.getBaseScriptUri() in bootstrap1.js to return an absolute URL. For whatever reason, Firefox does not seem to construct the URL properly for the final XHR request while it is evaluating dojo.js (works fine otherwise), so hopefully if we give XHR a full URL, then it won't have a problem.

Trick is to construct the URL correctly. Make sure baseScriptUri does not already have a full URL in there, and make sure it works for MSIE loading from local disk (at least for MSIE 6.0). In that case, it might not have a protocol for the URL. We could just do this work for firefox. Test Opera/Safari/Konqueror? to make sure they are OK with the existing scheme, and if so, target the fix for FF only?

I'm outlining a possible fix because I don't have time to do the fix right now, but hopefully the notes are useful for the final fix. Requires lots of testing across browsers to make sure we don't break anything else.

comment:2 Changed 13 years ago by James Burke

Owner: changed from alex to James Burke

I'll try applying a fix similar to the notes above.

comment:3 Changed 13 years ago by liucougar

Summary: XHR fails before dojo.js itself loadedrelative path in XHR calls fail in some cases in FF

this does not only affect "XHR fails before dojo.js itself loaded"

I noticed another problem: when XHR in an event handler attached to domnode in an iframe, the relative path to the XHR calls are resolved against the src of the iframe, not the window.location.href

I attached a patch to solve this, which works for me

comment:4 Changed 13 years ago by liucougar

a word about the patch: basically, it implements what jburke proposed

I used browser sniffer to only modify the djConfigbaseScriptUri? to absolute path for moz

comment:5 Changed 13 years ago by James Burke

Here was the patch I was working on last night, but its not quite there, and may be too complicated. Talking with cougar on how to get the final patch together.

	//Firefox 1.5 seems to get confused if we use a relative path for baseScriptUri
	//and that path is used by XHR as part of the evaluation of dojo.js. Force it to
	//be a full URL.
	if(drh.moz){
		//Call getBaseScriptUri so that the initial value is calculated correctly.
		var baseUri = dojo.hostenv.getBaseScriptUri();
		var loc = window.location.href;
		if(baseUri.indexOf("/") == 0){
			//Have a full path so we just need protocol, domain stuff.
			loc = loc.split("/").slice(0, 3).join("/");
		}else{
			//Have a relative path. Need to backtrack a bit.
			//Find how many directories we need to go up.
			var baseParts = baseUri.split("/");
			var removeCount = 0;
			for(var j = 0; j < baseParts.length; j++){
				if(baseParts[j] == ".."){
					removeCount += 1;
				}else{
					break;
				}
			}
			if(removeCount){
				var locParts = loc.split("/");
				loc = locParts.slice(0, (locParts.length - removeCount)).join("/");
				baseUri = baseParts.slice(removeCount).join("/");
			}
			if(loc.charAt(loc.length - 1) != '/'){
				loc += "/";
			}
		}
		djConfig.baseScriptUri = loc + baseUri;
	}


Changed 13 years ago by liucougar

Attachment: 1618.patch added

comment:6 Changed 13 years ago by liucougar

quoted from http://httpd.apache.org/docs/2.0/mod/mod_dir.html:

A "trailing slash" redirect is issued when the server receives a request for a URL http://servername/foo/dirname where dirname is a directory. Directories require a trailing slash, so mod_dir issues a redirect to http://servername/foo/dirname/.

comment:7 Changed 13 years ago by James Burke

OK, latest patch looks good. Thanks Cougar!

comment:8 Changed 13 years ago by liucougar

Resolution: fixed
Status: newclosed

(In [6100]) fixes #1618: relative path in XHR calls fail in some cases in FF

comment:9 Changed 13 years ago by liucougar

Resolution: fixed
Status: closedreopened

revert back r6100, turned off firebug xhttprequest logging, everything works fine!

comment:10 Changed 13 years ago by liucougar

Resolution: invalid
Status: reopenedclosed
Summary: relative path in XHR calls fail in some cases in FFXHR fails before dojo.js itself loaded

the other issue mentioned here is not related to this at all, will open another ticket for that

comment:11 Changed 12 years ago by (none)

Milestone: 0.4

Milestone 0.4 deleted

Note: See TracTickets for help on using tickets.