Our Webapp site has strange problem where we get occasionally huge number of page reloads from Apple iPad Safari.
What happens is that Safari opens keep alive HTTP 1.1 connection to our server and issue streams of GETs to it. The requests can arrive only tens of milliseconds from each other and it seems Safari is reloading the page as soon as it gets response to previous request. After sending 4-5 requests, Safari closes socket, opens new and same thing repeats for several minutes until it suddenly stops.
Things checked
Happens only with main page root url /
Page has no window.location.reload call on load that could cause this
Confirmed with tcpdump and wireshark that problem is real and happens between iPad device and our server. (i.e. not problem with haproxy, our servers or buggy logging)
Problem seems to be mainly with iOS 4.3.3
I can not ask the users and we have not repeated this locally with testing devices
All problem requests come from single IP that seems like VPN gateway of a school but from different random users (based on cookies same users may use webapp days successfully until problem repeats)
Has anyone idea what might be happening here?
Broken proxy somehwere?
iOS HomeScreen webapp bookmark gone haywire?
DoS attempt, though lame one
People turn zombies while using our webapp and instead of Brainsss they crave Reloadss?
Related
I'm developing a social media site. Over the last three months, I have noticed that a few percent of users are suddenly losing their cookies on iOS.
I investigated the circumstances and found that
It is not in private mode.
One day the cookie suddenly disappears. Once this happens, the cookie disappears within a few minutes or hours, no matter how many times the user logs in.
I have tried every setting to reproduce this on my iPhone. This should occur simply by changing some setting such as privacy in chrome, but I have not been able to reproduce it.
My website sets the cookie 'expires' field to six months. Most users do not lose their cookies.
Chrome goes into the background, stops, and when Chrome restarts, all cookies from all sites disappear.
I asked the user to try another website that uses cookies and they all disappeared as well.
Cookies only disappear when Chrome goes into the background.
The nginx access log shows that no cookie was sent.
This is happening on iOS 16.
I have not tested what happens when the iPhone is initialized.
I've asked users to check what happens in safari.
Do you have any idea what the solution might be?
The frequency of occurrence led me to believe that this issue must occur worldwide, but I could not find any information on it. Probably because most people use apps instead of the browser for services that require login.
I've got case when user wants to login and from time to time, the login page freezes (page is loading all the time) and nothing happens. The problem disappears when user open the app in “Incognito” mode in Chrome. I observed the same situation happening sometimes in Incognito mode too however, when performing some internally tests. The only way to solve this situation when it happens is to clear all caches and delete all web browsing history. I've got this response from the server https://monosnap.com/file/jmEkKWaGelHYzTODq385choJ8pke3J
I thought it the problem could be in some docker images (some container/image overrider) but I've only one container so this is not the case.
Is it possible to set automatic data cleansing in Rails app that the user does not do this? I'm using Rails and Grape in this app.
I have a HTML page with a Download app button. When clicked by an iOS user, it redirect the users to the App Store via itms-services. The link I used here is:
window.location.replace("itms-apps://itunes.apple.com/app/id578505616");
It looks like so on a mobile browser:
Facebook/Pinterest has an in-app browser which asks for the user's consent before redirect the user out of their app in the form of an Alert box with Cancel or Open app, which Open app opens the external link. It looks like this:
It looks like this with the Alert box:
Assuming the user is using an iOS device. The expected behavior here is when the Open app button is clicked, the user gets redirected to the App Store app. However, we are seeing about a 10 seconds delay before the actual redirection happens.
See videos below:
https://www.youtube.com/watch?v=_dgh7v-IsK8
https://www.youtube.com/watch?v=_LFHeRnBFgg
https://www.youtube.com/watch?v=82Y-kj-pMyw
Notes:
I can't seem to reproduce this at all times. It is only reproducible sometimes. Sorry!
Once a device is delayed for the first time, all subsequent links to AppStores will be fast, until roughly 1 day late. Rebooting the phone and/or clearing the browser cache and/or reinstall Facebook/Pinterest does not help reproducing this.
I tried to replace the itms-apps:// link with https://itunes.apple.com/us/app/trusper-tips-tutorials-how/id578505616?mt=8, but we were still experiencing the delay from time to time.
The delay seems to be exactly 10 seconds.
Why does this delay occur? This seems like a bad user experience.
My current theory is that the problem is on the Apple side. The reason being, once the Open app button is clicked, it is out of the hand of our website, as well as Facebook/Pinterest app. I presume, once the button is clicked, iOS is handling the actual context switch from one app to another. Therefore, it suggests that either the system call actually opening the URL is hanging, or the system call opening the App Store app is?? However, I haven't been able to prove either one to be true or false. Does anyone have a better explanation?
[Edit 04/02/2015]
I can confirm this problem still exists as of today on my phone (iPhone 5S w/ iOS 8.2).
I did some further research and found this article which I think is suggesting that this is a iOS system-related bug: OpenUrl freezes app for over 10 seconds
As there is no proper documentation on how it works, it is hard to pinpoint the cause of it.
Let me advance a theory.
Opening an app from browser causes a context switch; indeed from browser to App Store. So for the very first time it'd cost some time, while in subsequent times it will open faster as it will get opened from cache.
If you consider AppStore uses Keep-alive connection between iOS AppStore in device and iOS AppStore Server for the first time socket opening in server would seem higher than the subsequent times as subsequent request would reuse the same connection.
If the app is removed from the cache then it'd again take some time for the app to open and there would be a little network delay as the app would have lost the cookie for keep-alive connection then the app would have to endure the socketing opening cost.
There are also other factors like Safari hanging, resulting in some delay. You can read how Safari can be messed up here.
iOS doesn't have garbage collection, only things like ARC (Automatic Reference Counting). Each has its own advantages and drawbacks. Sometimes these drawbacks can surface and cause some problem; nothing is to be ruled out. For example a memory leak or app-crash might leave dangling pointers.
Technically, using itms-apps should give a little advantage over plain iTunes url because itms-apps should narrow down the search; itms-apps mean iTunes Music Store-apps.
A plain iTunes URL may be a Book (iBook), Music (iTunes), App (Appstore), etc ... so iOS might have to decide which app to launch.
I hope this helps.
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
I'm developing a small HTML5 web application for iPad that is intended to work in fullscreen mode (ie. it has the proprietary Apple meta tag, it is added to Home Screen):
<meta name="apple-mobile-web-app-capable" content="yes" />
The application basically fetches some data via AJAX and presents it to the user. The AJAX data are external (from a different domain, different server). I have the system setup for cross-origin requests, they work in online mode. In other words: the static data lie on server A, the dynamic data - on server B.
I created a proper cache manifest file, listing all static content of the site (HTML, CSS, images, JS) and then having the NETWORK: * section at the end - this way all the dynamic content (AJAX) is always retrieved from the network. The application fails "gracefully" if the requests fail, by displaying some fake content.
With the above setup, the following happens:
If I run the application while online, everything works ;)
If I disable the WiFi on iPad (pure offline mode), everything works as expected - the application falls back to the offline content
If I connect to the network again, but take the static-content server offline (the one that has everything cached), the application won't start; after spending a while in splash-screen, it shows me the a popup with <app> could not be opened because it could not connect to the server.; I can either choose Close or Retry.
The point 3 of the above is the one that drives me crazy because it was the only reason I started fiddling with application cache. Why doesn't the iPad web app fall back to cached content if the manifest file is not reachable? (not 404, the server is offline)
Is the answer to HTML5 iphone offline webapp completely incorrect? If not, how can I achieve this behavior on iPad?
Point 2 and 3 are completely different scenarios, so we cannot expect the same behavior.
In point 3, the device cannot fall back to the cached content when in online mode because if it do so, there will be no way to know for the user whether he is connected to the server or not.
I mean, in offline mode, the user knows it, and knows that he is with cached data. But in online mode, he expects to get the stuff from the server. If the server is not available, the user should be aware of this. If the server is not available and he is sent directly to cached data, the server error will be hidden to him, thinking that he is connected when he is actually not.
For example, web browsers can cache pages to be seen in offline mode. But if we are in online mode and try to open an unavailable page, we expect to see the error message, not a cached version of the page without any warning. We can go to offline mode to see the cached page if we want, but the correct behavior is to show the error to the user.