I am trying to load the host1 page, it contains iframe and the URL for the iframe is host2. But iframe with URL host2 is not loading properly.
I am loading host1 page through SFSafariViewController. If I load the same thing with the iPhone safari browser then it is working fine but not working with SFSafariViewController. As per my understanding, WKWebview has some limitations but SFSafariViewController doesn't have but still facing the issue.
I have tried the below options also in iOS14.5.1 but still, it is not working:
Enabled Allow Cross-Website Tracking by using NSCrossWebsiteTrackingUsageDescription in info.plist
Enabled Allow Tracking by using Privacy - Tracking Usage Description in info.plist
used WKAppBoundDomains also.
am I missing anything, please help me out?
Adding few more details:
When I am inspecting the code got the below errors with the mobile app SFSafariViewCotroller and the required content is not loading, but it is working fine with mobile, desktop Safari browsers and not showing any errors.
Refused to load {URL://_csrfRefresh=1} because it does not appear in the frame-ancestors directive of the Content Security Policy.
Sandbox access violation: Blocked a frame at {URL} from accessing a cross-origin frame. Ther being accessed is sandboxed and lacks the "allow-same-origin" flag
Attaching a screenshot below for reference,
I'm building a mobile app using WKWebView. I register custom url schemes image:// and thumb:// to serve assets from the native part to the web part of the app.
webViewConfiguration.setURLSchemeHandler(handler, forURLScheme: "image")
webViewConfiguration.setURLSchemeHandler(handler, forURLScheme: "thumb")
This approach works well if urls with a custom scheme are used in HTML. For example, <img src="thumb://watermarkly.com/1.jpg" /> works properly - WKWebView invokes my handler and displays the result. However, WKWebView blocks requests if I try to fetch these urls using XMLHttpRequest:
[Warning] The page at https://watermarkly.com/app/watermark/ was allowed to display insecure content from thumb://watermarkly.com/1.jpg.
[Warning] [blocked] The page at https://watermarkly.com/app/watermark/ was not allowed to display insecure content from image://watermarkly.com/1.jpg.
[Error] Not allowed to request resource
[Error] XMLHttpRequest cannot load image://watermarkly.com/1.jpg due to access control checks.
The only difference here is that "thumb:" url was assigned to an img tag, while "image:" url were fetched via XMLHttpRequest. Unfortunately, no other info provided in Safari Developer Tools.
The problem appears on a real devices only - everything works properly in iOS Simulator.
Is there something I need to configure to make it work for XMLHttpRequests as well?
Update
We switched from HTTPS to HTTP to make XHR to solve the problem.
Unfortunately, custom url schemes seems not to work on some iPhones. We have 5 customers with iPhones where nor switching to HTTP, nor sending Access-Control-Allow-Origin header help. We weren't able to identify which setting causes the issue - the problem cannot be reproduced on any of devices we have. Apple reviewer didn't have any complaints as well. Nor XHR, not getting images through urls work on these phones. One of the customers has two phones. Custom url schemes work on one of them and they don't work on the second one at all. He says they are identical and there is no Safari extensions installed. Unfortunately, we weren't able to identify what causes the problem. Beware custom url schemes may not work on some phones.
I have a single-page web app using Sencha Touch that has been added to the home screen on about 2000 iPads. I am looking to change the URL of the web app without requiring all of those users to delete the launch icon from the home screen, go to the new URL, and add it to home screen again. The app also uses a cache manifest to cache the HTML, CSS, JavaScript, and images, and the app is capable of working entirely offline.
Web pages added to home screen in iOS do seem to respond to HTTP 301 (permanent redirect) as expected, but I have found the behavior to be quirky in iOS 8 on iPad 2 devices as I will describe. I created an ASP.NET MVC website that I deploy under the same URL, replacing the Sencha Touch app in order to accomplish the permanent redirect. Here is the process I'm using and the behaviors I'm seeing:
When the app is launched from the old URL, it requests only the cache.manifest, and I return HTTP 404 to make the app stop caching.
The app loads and I have an event handler in the app's JavaScript for the applicationCache "obsolete" event that will call window.location.reload(true). The app will then reload and this time will ask for the previously cached HTML page (which is hosted at the URL root), and my ASP.NET MVC site will then return HTTP 301 to permanently redirect to the new URL.
Once the app hits the new URL, it begins downloading the resources from the cache.manifest at the new URL. I have an event handler on the "updateready" applicationCache event that will call window.location.reload(true) and reload the app. Once the app reloads, it will then request all resources (XHR requests to services) from the new URL as expected.
When I test this on an iPad 1 running iOS 5, this works exactly as I would expect. Once the resources from the new URL are downloaded and cached, it always makes every request from the new URL from that point. I can put the device in airplane mode and the app will work just fine offline.
This is where the quirky behavior begins, and I only see this on my iPads that are running iOS 8.x (I don't have any devices running iOS 6 or 7). I then close the app by pressing the home button and relaunch it from the home screen icon. When I relaunch the app, it will always initially go back to the old URL (iOS 5 always goes to the new URL), which is strange because the HTTP 301 from before should have prevented this. From here, there are two possible behaviors:
5a. Sometimes, it will ask for only the HTML page from the old URL (root URL), and in that case, it will get another HTTP 301 and will then redirect to the new URL, ask for the cache manifest, then load the app. From there and onward, it will never make requests to the old URL again when I open and close the app. When I put the device in airplane mode, the app works just fine offline. I have two iPad 2s running iOS 8.3 and 8.4, and this will happen about 50% of the time on these devices.
5b. Other times, it doesn't work so well. When relaunching the app after downloading the cached resources from the new URL, it will go back to the old URL and will not request the HTML page, and will instead request the cache.manifest along with the CSS and JavaScript. The the cache.manifest request will be result in another HTTP 404, but if I continue closing and re-opening the app, it will never consider the cache to be obsolete and will not request the HTML page again. Interestingly, I am only able to reproduce this on the iPad 2s. I have an iPad Air 1 running iOS 8.3 and I only ever see 5a on that device.
For the case described in 5b, it does request the JavaScript files. So, I went into one the JavaScript files and put in window.location.reload(true), which causes it to request the HTML page, which results in another HTTP 301. Now when this scenario occurs, it does send it to the new URL, but every time I close and re-open the app, it repeats the whole cycle. It goes to the old URL, gets the JavaScript, reloads, gets a 301, then goes to the new URL. When I put the device in airplane mode and open the app, it doesn't work.
I found that if I put the iPad 2s in airplane mode and run the app in the old URL, then run it again and do the 404 for the cache.manifest and the 301 for the HTML, then 5a will always occur. This sounds like a bug in iOS 8 (that possibly also exists in 6 and 7), and I'm trying to figure out a workaround that I can implement in my ASP.NET MVC website to redirect to the new URL that will work 100% of the time.
Any insights would be greatly appreciated.
I figured out how to avoid the quirky behavior. As I mentioned above, the app is listening to the "obsolete" event on applicationCache and is then calling window.location.reload(true) to grab the page again and get the 301. I found that if instead of reloading the same page, I redirect to a different page and back again, it works perfectly 100% of the time. It redirects to the new URL, caches the resources, then never asks for the old URL again. I also discovered that closing the app and opening it again after the cache is obsoleted has the same effect.
I know this is possible because today I browsed a mobile web page that said I have installed their native app, and prompted me to read their content in the app. (I haven't logged in, so they must have used some native checking mechanism.)
I know the web page can call out a native app by loading a custom url scheme like 'myapp://some/path', but how does it check if the url scheme exists before loading it? I want to do the same thing with my web app.
And I was seeing this on iOS, is this possible in Android, too?
The native checking mechanism is called Smart Banner. Apple added it to MobileSafari in iOS 6 and higher.
You add the following to your web page:
<meta name="apple-itunes-app" content="app-id=myAppStoreID, affiliate-data=myAffiliateData, app-argument=myURL">
The custom URL scheme is the way to go.
They probably delivered a transparent image by that custom URL, and checked if their image delivery mechanism was hit.
So in essence:
You download page
The page prompts your browser to hit their "checking service" (image with custom URL scheme?)
The page checks if the call to the checking service succeeded. If so, it prompts you to use the native app
I am developing an app using Appcelerators Titanium. The app consists of a webview. The webview shows i local page, iframe.html, and this iframe's src is pointed to a remote page.
However, this doesn't work out as i expected since it doesn't seem like the remote page can't store cookies when wrapped in an iframe. It works great on desktop and other devices. This seems to be an issue exclusive to iOS. I need the iframe, and i need cookies. What can i do to solve this?