[HTML5] Synchronous XMLHttpRequest deprecated
Monkey Forums/Monkey Bug Reports/[HTML5] Synchronous XMLHttpRequest deprecated
| ||
| "Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user's experience. For more help, check https://xhr.spec.whatwg.org/." is the warning I am getting in chrome 48. This affects LoadString() because it uses XMLHttpRequest. As a result I can no longer correctly load some files. Worked fine on chrome 47, tested on firefox and works there as well. |
| ||
| I just ran into this too, while trying to load the same file twice in two different functions called from OnCreate(), when testing in HTML5 |
| ||
This warning has always occurred for as long as I can remember, however it doesn't seem to adversely affect anything. This works here anyway...Import mojo Function Main() Local str:=mojo.LoadString( "versions.txt" ) Print str End Tested on Chrome 48 on both Windows/Mac. The angelfont sample also seems to work fine (the only banana I could find that uses LoadString). If you are having problems with LoadString, please post some runnable/testable code etc. |
| ||
| The above code on fresh monkey 86d , Windows 10, Chrome Version 48.0.2564.97 m gives me: Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user's experience. For more help, check https://xhr.spec.whatwg.org/. but fails on: http://localhost:59922/main.js Failed to load resource: the server responded with a status of 404 (Not Found)BBGame.LoadString @ main.js:366 Tell me If I should try to make a mojo example. |
| ||
| > Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user's experience. For more help, check https://xhr.spec.whatwg.org/. What do you mean by 'gives me'? Here, I get this printed in the developer console - but that's always happened. > http://localhost:59922/main.js Failed to load resource: the server responded with a status of 404 (Not Found)BBGame.LoadString @ main.js:366 You need a 'versions.txt' file in a data folder somewhere - I just copied in the monkey VERSIONS.TXT file (renamed to lowercase). Does the beaker/angelfont_example demo work? As far as I can tell, everything is working the same in chrome 48 as it always has. |
| ||
| Confirmed, working here too in Chrome 48 |
| ||
| Sorry for the sloppy first test. With a versions.txt (content: "Hello form versions text.) The code below Prints: 25 0 |
| ||
| I have no problems using 'LoadString' twice with MServer, but I think I remember this issue. It's likely the server returning 304 instead of the usual 200. This is an issue with a lot of synchronous XMLHttpRequest code, and it's something that caused many headaches when making WebCC. The best thing I've found to do is to use these header entries for consistent results. Technically, "If-Modified-Since" isn't the most proper way to do this, but it helps with maximizing compatibility. The only other options are to either keep track of response-strings, or use "ETags", like what 'regal.virtualos' does when they're available. |
| ||
| Hi, I confirm that since Chrome 48, we have a lot file loading issues here at Gloomywood (HTML5) . We revert to Chrome 47 waiting to fix it. If a file is loaded twice (or reloaded later like levels data) the second time gives an error and the file is not loaded. |
| ||
| Ok, I can confirm that LoadString twice fails the second time with both mserver and a real server, and that it does indeed appear to be a chrome (48?) specific issue. > The best thing I've found to do is to use these header entries for consistent results. That works - thanks! I'll upload a v86f update soon. > Technically, "If-Modified-Since" isn't the most proper way to do this Actually, it appears to be the key thing that fixes it for chrome. |
| ||
| ...and I guess I should add this to all XMLHttpRequests? |
| ||
| @marksibly: Yeah, that's probably your best bet. Either that, or you cache the results. Again, 'regal.virtualos' has a lot of this covered, and it's still making me think I should make a hybrid target. I already did most of the work in WebCC's data-folder, so it's not out of the question. This would also fix the problems some people have with resource loading. The codebase is modular now, so there's not much holding it back. I just haven't had the time or the need to make the target yet. |
| ||
| Fix coming Thursday apparently! https://code.google.com/p/chromium/issues/detail?id=570622&q=label%3AArch-x86_64&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Cr%20Status%20Owner%20Summary%20OS%20Modified Perhaps I should do some user agent detection kludge? I suspect this problem will vanish for good very soon, and it seems a shame to effectively disable caching forever to fix it. |
| ||
Ok, adding this to LoadString and LoadData in gametarget.js just before the xhr.send()'s fixes it for me.
if( navigator.userAgent.indexOf( "Chrome/48." )>0 ){
xhr.setRequestHeader( "If-Modified-Since","Sat, 1 Jan 2000 00:00:00 GMT" );
}
Think I'll go with this for now and see what happens with the next Chrome update. |
| ||
| @marksibly: I'm using Opera Developer, which is Chromium based. Given, it'll likely be patched here as well, but it's still an issue at the moment. It's probably best to keep that header addition as the default for a little while. For reference, this says "All is well." every time on FireFox nightly, but not Chrome or Opera. It kind of sucks, but maximum compatibility is usually the best answer. I find it weird that the other options don't work in more situations, but if it doesn't work, there's not much you can do about it. |
| ||
| Problem fixed with the last Chrome Version 48.0.2564.103 m Yes Mark, disabling the cache would not be a good solution. |
| ||
| Yes, the problem is fixed in the latest Chrome version. |
   |