I've got (actually my employer has) a mobile website that enables Safari integration (for iPhones and iPads) - meaning that customers can bookmark it to their home screen and then it would behave as a standalone web app (no address bar, custom icon, start-up image etc).
It works all right except that one week ago (coincidentally soon after apple has released iOS 6.1.2) some of our customers (6 of them initially) complained that they no longer get the normal content but a '404 page' of a public wifi provider (The Cloud owned by Sky here in the UK). After a bit of investigation we've figured that at some point those customers connected to the Cloud wifi without actually logging in (it's one of those providers that would redirect you to a login page to enter your credentials, after which you can carry on browsing). The thing is that even after switching back to their private wifi or mobile data connection the application would display the Cloud's page.
This only happens (as far as I can tell) when the application is launched via the bookmark (I couldn't see this behavior when using it from safari).
What happens is that the customers would connect to the cloud wifi (without logging in), they would open the application at which point the router will issue a redirect response to their login page; the application would cache the login page and it will always display it whenever using the bookmark again. (I've performed a capture when this happens and there are no requests being made at start-up whatsoever).
Even weirder, in this situation, if removing the existing bookmark and adding a new one will show you the same cached page (with the whole operation being performed away from the Cloud). We've fixed this by adding a unique identifier to the URL each time we hit the bookmark screen (this indicates that the web apps' sandboxes are linked to the url, which is to be expected).
What we're trying to achieve is to have the application properly recovering after the customer has moved away from the Cloud. But there doesn't seem to be a straight forward way to do this.
Furthermore there's a level of inconsistency in all of this - most of the times when the flow is performed I will see a 404 page (a custom 404 page https://service.thecloud.net/service-platform), but sometimes I would be properly redirected to the login page, in which case the application would not break.
My assumption is that there is a weird race condition in the standalone web app application model causing the browser not to properly handle redirects (and actually caching 404 pages). I've raised a support incident with Apple (which eventually turned into a bug report) but it might take a while and I'm trying my best to figure out a workaround.
Any ideas, maybe someone has seen this before?
The issue is aggravated by the fact that I need to have a 5 minutes walk ever time I'm testing any fixes; I've tried creating simple test forms, but I wasn't able to reproduce the issue, where as with the full app I can do it pretty much every time.
Here's a summary of the steps to reproduce:
Via private wifi (or mobile data connection) add a bookmark to a website (I've managed to reproduce it with quite a couple of apps that support safari integration as described above)
Open the application to review the normal content
Connect to a Cloud hotspot and open the application from the bookmark (open-close it for a couple of times if you don't get the 404 right away)
Connect to the private wifi (or mobile data connection) and open the application via the bookmark -> you'll see the same 404 page again
In the end the fix was to add a unique query string parameter with the initial page request (pretty easy with the setup we already had, via the launcher page). I've filed a bug report with Apple which they've acknowledged by linking it to a previous item. Here's a post on the topic:
http://blog.onos.ro/ios-6.1.2-caching-issue
Related
This is an intermittent behavior with the progressive web app version of my site.
I made a website with React. Then I visited it with my iPhone 5 and saved it to my Home screen with Safari's "Add to Home Screen" feature. The behavior is different between (1) visiting the site using the home screen shortcut and (2) opening Safari and going to the page that way.
Doing (1) has the problem. If I do that and then go to the Home screen and touch the shortcut and go back to the website, the page turns all white for about 1-5 seconds, the internet connecting indicator spins and the page appears. Sometimes the page returns to the state I left it and sometimes it reloads entirely. Doing (2), the page doesn't reload at all and doesn't try to access the internet. Same with accessing the site using Chrome.
It seems to completely reload more often if more time has passed since I .
According to Chrome developer tools, a Service Worker is activated and Lighthouse gives the site a perfect PWA score.
I have questions... Why is the behavior different when accessing the page these two ways? Why is it trying to access the internet or doing anything at all every time I switch from the Home screen or another app to this app? Why is it totally reloading the page sometimes? How do I make it not do this? I want it to work offline and I want it to not attempt connect to the internet unnecessarily.
We have link functionality in our web application that when clicked, browses to a page on our server that performs the following:
Tries to open the custom url to our ios application
If this fails, it redirects the user to our ios app store to download the app.
This actually all works perfectly well.
However, it creates a weird corner case, where after a user has done this and finished, if they come back sometime later and open their safari on the same phone, if our web link is still the active tab, it will redirect them again to our application.
The cause of this is fairly obvious, but we are struggling to come up with a solution for it. Is there any known to rectify this behavior, either through a different mechanism then I described for opening the application or through somehow killing the page simultaneously?
I created a router that connects to facebook to get some info before a user may access the internet.
First they connect, get the Captive Portal Page and then continue to a facebook login. Since the upgrade to iOS7 it fails to load the facebook login page. On my mac with the Captive Portal Assistant it has no problems and even on the phone itself while using the iOS version of safari there are no problems.
What is going wrong here? Is facebook filtering request from the iOS7 Captive Portal Assistant or is Apple doing some sneaky stuff here?
It seems the problem is widespread and only related to facebook.
Update: I worked with the beta's and they worked fine a few weeks ago. Now with the same beta version it doesn't anymore. So another point for the facebook explaination.
Regards, Cas
This problem was fixed by Apple since IOS 8. But as all iPhone 4 users can't upgrade to IOS 8 this problem is still one.
The IOS 7 devices check for the following domains:
www.appleiphonecell.com
captive.apple.com
captive.apple.com
www.apple.com
www.itools.info
www.ibook.info
www.airport.us
www.thinkdifferent.us
Whitelisting this domains stops the login mask to be appearing as the IOS device thinks, that the internet is working as expected. This way you have control on the things which happens, as the IOS device does not interrupts anything, if you use a normal browser for login.
If you don't whitelist the domains, the following thing happens. I debugged it on routers with several IOS devices and they all did mostly the same:
If you connect to a wifi, the IOS device tries to connect to one of the domains, which are listed above. If it can contact one of the domains, it tries another one. If it can't, it starts the redirect, which is controlled by the router. Sometimes it query one or more domains, before it thinks, that the internet is working.
After the check, the login screen redirects to your router and then to the login screen of your captive portal. This behavior stayed the same as it was on IOS 6 or before.
Now you start an oauth login to a 3rd party provider like Facebook, Google or Twitter. And now the difference appears. You can check it on a router, if you run it in debug mode. As the IOS device goes to an other domain for oauth login (like www.facebook.com) the iPhone thinks, that something changed and starts to query one of the apple domains, which are listed above. The user sees only a white screen and in the background the IOS device tries to contact one of the domains repeatedly. For the user this seems to be an error, as the screen stays white or takes very long to show the login on the 3rd party provider. Sometimes it stops loading and nothing happens forever.
To avoid this behavior, you must whitelist the above listed domains. This is a not a common behavior for IOS users, but this way, your browser have the control of the login session and the IOS device don't interrupt it as it does with the login screen.
Some shallow parts of information is reported on the following sites:
https://supportforums.cisco.com/docs/DOC-36523
http://www.cadincweb.com/why-your-apple-ios-7-device-wont-connect-to-the-wifi-network
https://discussions.apple.com/thread/5355766
I couldn't find a detailed description of the problem and found the one above myself by debugging all parts with some routers and IOS devices like iPhones and iPads.
I've just tested various router settings and noticed that iOS 7 is NOT trying to contact above mentioned sites/URLs when router's DOMAIN field is blank.
My guess is that blank domain points to a consumer-type network set up and Apple is not expecting a Captive Portal at such network. If you have access to administer your router see if you can clear out the DOMAIN field (and restart/retest).
I found my solution to my problem. (a while ago, but I found this post again)
First I found out, iOS makes 3 calls, first to check, second to get the page that needs to be displayed, third to check again after the pageload. Then I discovered, for every POST or GET action made by the page, regarding of the source page was refreshed, iOS checks for an active internet connection. Since the facebook api makes a lot of calls, the browser starts stalling(possible in combination with QoS on my router) and freezes the page.
My Solution:
Since I am in control of the DNS records of the Router I use, I redirected all domains towards my own server.
First I saved the check request, this to later identify the user when he comes back for the 3th request.
When the second request comes I just display an info window that every thing is right, and the user has to click the "Done" button.
The page is loaded, so iOS checks again, but i recognize the user so I display the OK-code Apple also displays. The "Done" button us show, and the user has "internet", according to iOS..
On the page that I display, I instruct the user to open the webbrowser. When he does, he opens a page and my portal with the right page is shown(I can detect this based on the Browser Agent). Then my facebook api start doing its job, and of we go :-)
Let me know if someone needs some more info on how to detect or maybe even a code sample if necessary.
Extra Information
To capture a user on your own server, redirect every request to your processing page using for example .htaccess. The request is made to a domain with a subfile e.g:
http://captive.apple.com/getrT09Nx7G/YNrnUOulnDj/3cfrq3M40iR.html
To keep multiple users apart, use the unique url the device tries to contact when checking for internet, in this case: /getYT09Nx7G/YN1nUOulnDj/3cfMq3M40iR.html
I have an application built using XPages' mobile controls. On an ipHone the application behaves as I would like in the standard Safari browser. When I take the url and add it to the Home Page as an icon and use the application from there every time an action I take invokes a native application (Maps, Contacts, Phone, attachment viewers etc.) when I switch back to my application I am immediately asked for my userid and password again. Is there a way to control the behavior to not lose the login credentials the same way that the standard Safari application seems to.
This is a limitation in iOS. If you save it to the home page like that it works, but it will NOT multi-task. That's the problem. So it doesn't remember where you were or anything like that.
As David mentions it starts all over again when you switch back.... The problem is not only the credentials - it is also all the information you may have entered or where you have navigated to in the "app".
This is why I am changing to another approach. I am starting to write apps as web-apps that run locally (i.e. cache the ressources and run on the cached versions of the JS-files, CSS and images). Then I implement a localstorage where you can track where in the app you are - and return to that place again. This way you do not need the authentication for running the app - only for synchronizing the information with the server. My approach is to save data locally and sync them to the server (as a sort of replication). This obviously gives more work - but it also gives a better user experience since you can run the "app" without being connected.
I have tried to control the caching locally using a cache.manifest file. This can be done, however, it is a pain. Therefore, I am now using Sencha Touch which really does this nicely.
/John
PS. I think you may be able to handle the login issue by using the XPage Dojo login custom control (http://www.openntf.org/internal/home.nsf/project.xsp?action=openDocument&name=Xpages%20Dojo%20Login%20Custom%20Control) - however, it does not solve the issue with reloading the page...
It seems the secret to success here is NOT to tell Safari the XPage is capable of acting as a mobile web app. Add the following code inside for the XPage to ensure this is the case.
<xp:metaData
name="apple-mobile-web-app-capable"
content="no">
</xp:metaData>
Note: You can still provide an icon for the home screen, its just that icon will now act more like a bookmark with the Safari controls and (more importantly) you can switch between applications and when you return to Safari it will display your Xpages app just as you left it.
2nd update, March 2014: Apple closed the bug saying they don't have enough information, but my project is a big PHP application that I can't (and won't) fully send to Apple for them to reproduce this problem. If anyone has a shareable, simple, pure HTML app that exhibits this problem as well, please let me know and I'll submit it to re-open the bug hoping they'll look into it.
1st update: as more users are reporting this issue and nobody has a clue, I have filed a bug report at Apple. If anything useful comes out of that which is not under NDA, I will post it here.
After installing a (jQuery Mobile) web app I am developing to the home screen of my iOS 6 device (iPhone 5), the network activity indicator in the status bar at the top of the screen keeps spinning even after the page is loaded completely. The behavior shows only when the page is opened through the web app; surfing to the same page in Safari on the same device doesn't show the infinitely spinning activity indicator.
Removing all AJAX calls and page content doesn't make a difference; the problem persists even when the web app consists only of an empty page like this:
<html>
<head></head>
<body><br/></body>
</html>
The issue was solved by deleting the web app from the home screen, surfing to the page in Safari and re-adding it to the home screen as a new web app.
My guess is that the problem lies in the meta data that iOS stores at the moment a web app is added to the home screen (such as the values in the apple-mobile-web-app-capable and apple-touch-startup-image meta tags).
At least some of that information does not seem to get refreshed when accessing the page as a web app, even when it starts serving completely different content (such as the empty page shown in the question). I know this is true for the apple-mobile-web-app-capable meta tag; adding that tag to a site that has already been installed to the home screen does not suddenly make it a native-looking web app; the tag has to be present at the moment of adding the web app to the home screen.
I think I must have installed the initial web app at a stage of development where the page referred to a non-existent resource (such as an image, CSS or JS file), resulting in a web app that keeps looking for non-existent content even though the current web page is no longer referring to it, possibly explaining the infinite activity indicator behavior.
I am not certain that that is the cause, but it does seem the most likely explanation for this issue.
If you encounter this; check that all resources your page refers to exist, then delete and re-add the web app to the screen to see if it fixes the issue.
I have the exact same issue, and it goes away when I remove the bookmark from the homescreen. But the activity indicator starts spinning again after the webapp has been used for some time.
I don't see any failed requests in Apaches access log during initial load, and no requests appears when the activity indicator starts spinning, so I don't think the problem is about a non-existent resource.
However, I see in the access log that iOS Safari insists on requesting a whole batch of Apple-specific files such as apple-startup-image and apple-startup-icon when in full screen mode. This is just like how Google Chrome insists on requesting favicon.ico (sigh!). Sadly, when I satisfy Safaris thirst for apple-files it doesn't stop the spinning disc :-(
I have had the Mac OSX web inspector enabled for my webapp and it registers no network activity or other issues whatsoever.
In the Apple manual (http://support.apple.com/manuals/) page 12 for the iPad it states that the activity indicator is for "network and other activity". It doesn't say that Safari uses the indicator for anything else but network activity, but maybe it's a hint.
For the time being, I have come the temporary and unsatisfying conclusion that it's an iOS issue that's beyond web developer control. I'll keep hacking at it and post any new findings here. Perhaps together we can uncover the mystery :-)