I have a java web application which works well on all devices, all browsers except for Microsoft Edge on iPhones. On Edge on iPhones, as the user fills in the input fields and proceeds to the next page, all data except for the date fields get lost. This problem doesn't occur all the time. Sometimes, all information is saved properly and nothing gets lost. Has anyone faced similar issue? Is there a way to get developer tools in Edge on iPhones to debug and see if anything comes up?
Related
I am working on a web page, which I want to test on my iPhone. However, when I visit the website from my phone in either Firefox or Safari it is an old version of the website that opens. I have tried to clear cache and history as described here, but it is still the old website that appears. I have also tried to de-connect my Firefox account and restart both the app and the phone. I have checked in a browser on my computer and here I see the new website and any changes implemented instantaneously.
Do anyone have similar experiences with such an issue and how to solve it?
Edit 1: After a while (couple of hours) I tried again and it was indeed the new page in the mobile browser. I still don't however understand why there is latency in a mobile browser and not elsewhere, i.e. where and why is the old page cached on a mobile device even though history and cache has been cleared?
Edit 2: I have now also discovered that the same issue applies to all other non-mobile browsers than FirefoxDeveloperEdition, so this browser must be doing something the others don't.
I faced similar issues in past. It depends upon your hosting provider. Usually it takes no time to update web pages but sometimes average hosting sucks.
Try opening webpages in incognito mode/private mode.
My problem was solved by running cache-purge from my provider's SSH service.
I tried to search on the internet for this. I got a related question here but could not get a convincing answer.
I have a web page built in asp.net. I have google recaptcha on this page and is working fine on all desktop browsers and android mobile phones.
The problem is with iphones. The recaptcha does not show the image grid for the user to verify them. When the user touches the checkbox is simply gives a "tick" and lets the user through.
The model of iphone I have checked in is iphone 5C (safari) and iphone 6S (chrome 50) but I think the problem should be with all the models.
Please note it is working fine on simulators like chrome simulators.
The web page is as below:
http://www.infochoice.com.au/infochoice/contact-us.aspx
This is a live webpage so request you to please be careful and gentle in adding comments in it.
I have not added any code here in this question as I think it is more iphone device specific issue and has nothing to do with code.
Will update the question if requested.
Please help! Thanks in advance!
reCAPTCHA actively considers a user’s entire engagement with the CAPTCHA—before, during, and after—to determine whether that user is a human.
In cases when the reCAPTCHA risk analysis engine can't confidently predict whether a user is a human or an abusive agent, it will prompt a CAPTCHA to elicit more cues, increasing the number of security checkpoints to confirm the user is valid.
Therefore some users may just be shown a simple checkbox while others may face image grid verifications.
See this blog post for more details
https://security.googleblog.com/2014/12/are-you-robot-introducing-no-captcha.html
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 :-)
Now, this sounds very strange but we have an application which supports only particular browsers and in order to keep a close look on alll the requests coming, we have a log server which logs all the detailed information about incoming request's userAgent.
Now, some of the IPad users complained that they used to see NotSupported.html page, which is the page we redirect users to when the page is not supported. They ONLY see it sometime.
We we looked at our logs and sometimes Ipad requests were coming a Mozilla 0.
I am using HTTpRequesBase's UserAgent Property to read it. and I am not sure why IPad identifies it self as mozilla 0 and that also ONLY sometimes. Anyone ahd similar experince?
Safari is not the only Browser in the Apple devices.
When I go with my Chrome for iPhone to http://www.whatsmyuseragent.com it shows Mozilla as well. So the best assumption is that those users are not using Safari.
EDIT: It does come with enough information to know it is an iPad, I myself have a project that matches iPad in the User-Agent string and works for Chrome/Safari and I don't have Opera to test right now but I guess it works too (anecdotal on no complaints).