Ajax call from JS code cross-domain

jaynabonne
A bit of an obscure question, but I'll ask it here in case anyone else is doing obscure stuff.

I'm trying to integrate a JS library into Quest (one of mine, just for fun, to see if I can), and the code uses $.ajax to load files. However, when I provide the "GetFileURL" url to that API, I get an error like this:

XMLHttpRequest cannot load quest://local/helloworld.txt?_=1453648271432. Cross origin requests are only supported for protocol schemes: http, data, chrome-devtools, chrome, https.



I had this problem with Chrome before, and I had to resort to using a local (node) web server to give it a URL it would be able to load from. I hadn't expected to see this with Quest. And using a web server won't work, as Quest is serving files itself.

Is there a better URL to use to access local files from a JS Ajax call if the normal "quest://" ones don't work? Or is it just hopeless?

Ideally I'd like to be able to load files on demand from the JS code, as one file can "include" another, and the code needs to be able to resolve those references itself without having to go back to the Quest ASLX file to load the data.

If there is no other solution, I'll have to resort to something less ideal, but let's shoot for ideal first. :)

Alex
There's probably a setting in CefSharp (the .net binding for Chromium embedded that Quest uses) which would allow this.

Could you attach a test file?

jaynabonne
Here's my current working folder. More files than you probably need, but it will do the trick.

The two main file to examine at this point are rif_glue.js which has the "init" function called by the game start script (and sets the load prefix) and rif_engine.js, where it does the actual ajax call.

But if you just start up the game and then examine the HTML console, you'll see the error.

Thanks!

jaynabonne
Just an FYI. I tried the route of calling up to the ASLX file and then sending the data back down, but I ran into a quirk with GetFileData, which is that when it joins the lines together into a single string, it doesn't add *any* whitespace where the EOL was. So if I have a file like:

line one
line two
line three



I get back as a string

line oneline twoline three



which is useless in my case (and I suspect a lot of others). I realise this is just implemented with C#'s File.ReadAllText, but I can't believe they implemented it like that. Doesn't seem entirely useful, unless it's meant for a different case than reading a file with tokens. Even human text would get mangled with that. (I could make a request to have the implementation of GetFileData changed to use GetFileLines followed by a Join with spaces, but I'm not sure it will be an issue long term if this other problem can be fixed. Otherwise, it will be.)

jaynabonne
And just to round this out, if the file methods don't work (or if changing Chromium won't be available for a while), I can fall back to a plan I had originally, which is just to have the text in the .aslx file and inject it down. So it's no problem regardless.

This topic is now closed. Topics are closed after 60 days of inactivity.

Support

Forums