Same here. I can't log in to Google Drive. I get "Failed to refresh file list" error.

Dropbox is working.

Could be CORB related again, any changes to that magic flag @AshleyScirra ?

Yeah I suspect so - it sucks that we have to rely on a flag, Google specifically say those can't be relied upon, so it seems likely they changed some detail about the flag. It's a shame we can't find a real solution, even if we update the flag it could be changed again, so this is very brittle...

I'm not really sure why CORB is being triggered in this situation and not in the browser. I wonder if Google has some magic whitelist in place that is only in Chrome, not Chromium which is allowing their APIs to work correctly.

I don't think I found any other workaround related to this when I looked at it last time.

Looking at the comments from #2029, I'd guess Google Drive is doing some kind of user agent sniffing, fails to recognise the NW.js user agent, falls through some kind of browser check, sends the wrong MIME type, and then fails CORB.

Here's the UA for the latest desktop build:

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (@ac9418ba9c3bd7f6baaffa0b055dfe147e0f8364) NWjs/0.35.0 (like Chrome/71.0.3578.80)

And for actual Chrome 71:

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.80 Safari/537.36

Maybe if we make NW.js' user agent more like Chrome's we'll get away with it.

Nope, still fails to load even with the identical UA that Chrome 71 uses. Also I can see it's making Google API calls which respond 200 OK, and have a content-type: application/json; charset=UTF-8 which looks correct, so I guess it's something else specific to CORB in NW.js...

I don't think that content-type is correct, according to their explainer it must be "text/json", "application/json", or any MIME type whose subtype ends in "+json"

So it could be they don't understand the charset value

So after some more investigation, yes, the flag was changed - it was removed entirely! (Serves us right for using a band-aid solution...) So now we have no way to disable CORB in NW.js other than disabling the same-origin security policy entirely, which seems dangerous.

It's not clear why NW.js only is affected by CORB. Maybe they made a change that affects it. I filed an NW.js issue here to see if they can help: nwjs/nw.js#6889

If we cannot find any resolution from there, our only recourse would be --disable-web-security...

NW.js fixed the issue quickly which is great. The latest desktop download should be working now: https://www.construct.net/en/forum/construct-3/general-discussion-7/construct-3-desktop-build-beta-131317 - can someone confirm the fix is working?

Fixed, thanks!

It works, thank you!

Thanks for confirming!