breautek commented on issue #1519: URL: https://github.com/apache/cordova-ios/issues/1519#issuecomment-2572151780
> As for the app still launching blank, it looks like I am now dealing $ionicPlatform.ready() firing I can't really speak for this or what ionic is doing. It's possible that the plugin manifest is messed up and it's calling on `deviceready` because it thinks there is no other plugins needs to be loaded. If that's a case, removing the platform and re-adding it might fix it. > We can close this issue, but I would appreciate if someone could comment on why adding those two preferences fixed the issue when I never had to have those preferences set in my app before all the latest upgrades mentioned above. Cordova webviews on iOS can operate in two modes. Again, I can't speak for what ionic defaults too, they might alter the default configuration if you're using the ionic webview. So from here on I am strictly speaking about what default cordova webview by default. By default, if you don't specify a `scheme` it uses `file://` protocol instead, for backwards compatibility reasons. In both browsers and webviews, a documented loaded over `file://` is treated as having a `null` origin, or no origin, and every request is considered a cross-origin request, including requests to other `file://` paths. Safari only supports cross-origin requests for http/https resources). So attempting to XMLHttprequest to a `file://` resource will fail. I believe this worked on the older `UIWebView`, but since cordova-ios@6, as per Apple requirements, `WKWebView` is used which has the CORS policies implemented. If you're using angular which makes heavy use of XHR requests for templating, you would need a plugin to redirect XHR requests to a native solution instead of using the browser's XHR API, or you would have need to migrate your application to use schemes, which is where those preferences comes into play. Using schemes makes your domain origin be `app://localhost` (as per your example snippet above), and XHR requests to local resource assets will also be against `app://localhost`, which makes the request a "same-origin" request and thus CORS policies are not in effect. Considering that you said you're upgrading from cordova-ios@6 to 7 and that you have some plugin issues, I'm guessing you might of had a plugin to handle XHR requests in some way and that plugin is for some reason not working properly which led to your CORS issues on cordova-ios@7. Otherwise I can't explain why you wouldn't have observed these issues on cordova-ios@6. Two common approaches to solve the issue before schemes was a thing was to use a local webserver server plugin, or a XHR plugin that remaps XHR requests to native http client APIs (which aren't bounded by CORS). Neither of these options are recommended IMO. Using schemes is the proper approach. The CORS related issues apply to any application making use of the `WKWebView`, which today all applications wanting to use a Webview must use the `WKWebView` today (unless if you're in the EU and taking advantage of EU exceptions). Hopefully this answers some things. Let me know if there is anything unclear and I'll try my best to explain. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
