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.
Related
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.
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 have a web site that I'd like users to be able to add to their home screen. Users will switch between this saved "web app" and a game frequently.
The first problem is that when a user comes back to the saved "web app", it displays the splash screen every time even though it wasn't closed. This is undesirable. Further, when a users clicks on a primary navigation element, it switches the user over to Safari.
How do I get the app to "save state" and not re-load the app when coming back to it (when it hasn't been closed)? How do I get it to load links clicked within the same domain to load within the saved "app" rather than loading them up in Safari?
Safari doesn't reload a page when you switch away from the app and come back, so why does a web site saved to the home screen have to reload when pulled to the front?
I don't want to use an offline database, I don't even need the app to work while offline because it needs to tie to a live database that's constantly changing. Therefore a working offline isn't intuitive because the data would be outdated and irrelevant. Therefore, I don't need cacheing either (except maybe a few resources that don't change often). I just want the darn thing to "save state" and not reload every time the user comes back to it. And links clicked within it, shouldn't take the user out of it unless they are links to a different domain.
I've searched and read and searched and read, but I'm not finding anything other than articles about making a web app work offline. That's not my goal. My goal is to make it behave like Safari does in that if it's not explicitly closed, it keeps it's state.
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
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 :-)