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.
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 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.
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
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?