Opened 8 years ago

Closed 7 years ago

Last modified 7 years ago

#14222 closed enhancement (fixed)

Not existing i18n file causes Firefox 7 to process dojo if website has a 404 reply handler

Reported by: andreas.stankewitz Owned by: Rawld Gill
Priority: high Milestone: 1.8
Component: Loader Version: 1.6.1
Keywords: i18n loader 404 FF7 Cc: andreas.stankewitz@…
Blocked By: Blocking:

Description (last modified by Kenneth G. Franqueiro)

This is a suggestion to make loader.js more fault tolerant to bad resource files.

A special setup, that is maybe not so special for websites with CMS in international environments, caused dojo failure with Firefox 7. The setup:

Using dojo with i18n in a language that does not provide a translation file, e.g. PasteFromWord? (Editor).

Having a 404 error handler installed on the website, that forwards to the home page that shows a special message like: "Sorry, the file is not available", but without returning a 404 code.

loader.js tries to parse the returned page as json, and of course fails. The problem with Firefox 7 is, that further dojo use fails, too. Firefox 4 did not have this problem, and IE and Chrome also not.

It took quite some time to find the underlying problem, and I wonder, if it is not possible to make loader.js more fault tolerant. My suggestion:

Wrap this line (116 in 1.6.1) into a try/catch block:

	var value = d["eval"](contents);

Could look like this:

	var value = d["eval"](contents);
	if(cb){ cb(value); }
	console.error("failed parsing " + uri + " with error: " + e);
	contents = null;

The loader is too central, so I cannot oversee the consequences of this change - I'm sorry that my resources are too limited to do further investigation, but I think, this enhancement would help a lot to make dojo more stable, as a certain webserver configuration would not make dojo to fail working.

Change History (5)

comment:1 Changed 8 years ago by Kenneth G. Franqueiro

Description: modified (diff)
Keywords: FF7 added; Firefox 7 removed
Milestone: 1.6.2tbd

Marking this as tbd as it's unlikely to land in 1.6.x (since it doesn't sound like something that would be a 1.6-introduced regression). I'd be curious whether this same problem is reproducible on 1.7, given the new loader.

Moreover, not sure how much priority this will be given, given that a server returning a 200 in a 404 case certainly seems like invalid behavior beyond our control. The fact that it's causing further issue on FF7 is interesting though...

I am not a loader expert, but it seems to me that try/catching that line of code might hamper error reporting in cases where you really do want the loader to inform you of a problem when attempting to execute code in a loaded module, and I also can't imagine it'd be at all good from a performance standpoint either.

comment:2 Changed 7 years ago by Rawld Gill

Status: newassigned

comment:3 Changed 7 years ago by Rawld Gill

Milestone: tbd1.8

comment:4 Changed 7 years ago by Rawld Gill

Resolution: fixed
Status: assignedclosed

In [27774]:

improved sniffing of i18n bundles in backcompat mode; fixed test; refs #14375; fixes #14222; refs #14226; !strict

comment:5 Changed 7 years ago by Rawld Gill

as of [27774], any failure loading a bundle in legacy sync mode will simply result in assuming that bundle is === {}. Note this is basically how it worked in 1.6- since the loader would request bundles until it got a 404 error...basically, because the algorithm effectively ignores more programming errors.

If a bundle does fail to load, a console.error message will be logged.

Note: See TracTickets for help on using tickets.