document.write in getScriptPath throws exception when library loaded asynchronously

[edg2s]

Chrome throws the following exception:

Failed to execute 'write' on 'Document': It isn't possible to write into a document from an asynchronously-loaded external script unless it is explicitly opened.

Either another technique should be used in getScriptPath or the exception should be caught and handled gracefully.

[edg2s]

I see in #87 (comment) the suggestion is hard-code a script path, but editing the library is evil. This should be a config option.

[mholt]

I wouldn't agree that editing a library is evil, especially when the edit is well-documented: it's much cleaner and reliable to just hard-code the path. Feel free to tweak it according to your needs.

Catching the exception doesn't help because the document.write has already failed, emptying the body of the page (in Chrome). Firefox is strangely silent, though the page remains devoid of life.

If it were a config option, the script would have to be loaded before the config could be processed, but by that time, the exception has already been raised.

[edg2s]

I wouldn't agree that editing a library is evil

Seriously? That's part of the point of having a library in the first place. If I'm dropping in updates I don't want to have to worry about rebasing every library because I've made modifications.

Catching the exception doesn't help because the document.write has already failed, emptying the body of the page (in Chrome). Firefox is strangely silent, though the page remains devoid of life.

I was getting a warning in Chrome but you can still check for the existence of the script tag. Will have a look at other browsers.

If it were a config option, the script would have to be loaded before the config could be processed, but by that time, the exception has already been raised.

That's a design flaw then. You can provide configuration after the library has loaded and lazily evaluate anything that might throw an exception.

[edg2s]

So for the synchronous case at least you can avoid document.write using

var scripts = document.getElementsByTagName('script');
return scripts[scripts.length - 1].src;

Doesn't help you with the async, but at least it doesn't explode fatally.

[mholt]

And if async is used, that will silently get the wrong path with no way to tell that it's wrong.

[edg2s]

Right, but you can re-configure it later via globals. Better than having the library unusable.

[mholt]

What we've got now ensures the developer will be aware of a problem, which is better than a silent failure. You're the only one to speak up who's refused to hard-code the path. There are ways to fix the problem you're having, and they're well documented. I wish you the best of luck.

[edg2s]

You can detect if the body has finished loading to determine if the script is asynchronous and throw and error to the user stating they need to override the config.

[edg2s]

I suspect the reason no one's complained is that it's pretty rare use case, but in general it's a terrible idea to require users to modify a library.