I am trying to solve a mystery:
A page from a React web app can be loaded in Safari on iOS
That page can be loaded in Chrome on iOS if you choose "Request Desktop Site"
That page is blank when attempting to load it in Chrome on iOS if you go with the default "Request Mobile Site"
The page works fine in desktop browsers
I have taken steps to enforce a timeout on the server side, in case there is a connection that is hanging. But when I consult the logs, the requests complete quickly without any of the usual follow-on activity. My guess is that there is a JavaScript error of some kind that is causing the React app to bail.
What is a good next step that might be helpful in troubleshooting this issue?
ETA: Added new information that confirms the requests are making it from Chrome to the Golang server, as expected.
I think what's going on is that the "Request Mobile Site" mode falls over when there's a large JavaScript bundle, whereas the "Request Desktop Site" doesn't for some reason.
For anyone who runs into this situation, something that worked for me was to decrease the amount of JavaScript that the iOS Chrome app has to load, e.g., using code splitting, user agent sniffing and redirection to a less memory-intensive page in the case of iOS Chrome. After doing this, things worked fine. I'm guessing that less memory is available to apps running in the "Request Mobile Site" mode than in the "Request Desktop Site" mode.
Related
I have a simple app deployed in GitHub pages (my web-app). The app has some inputs and I tried to use it offline on my Android phone, by clicking the download button on Chrome, which downloads the HTML; but all the inputs and buttons are disabled.
If I click the file that was downloaded in 'Files' and try to open it on Chrome or Brave, all the inputs appear to be disabled, but when I refresh (or enter online mode again), they return to be available.
Is there a work around to this?. I want to build an offline web-app, but it seems that forms can't be incorporated.
I tried to test this error in dev tools using my computer, since there is an option to emulate being disconnected from the internet. But the doesn't go very far, since the website only appears with 'No internet' and not really with the offline view that I get from my cellphone.
I have a Trusted Web Activity app that is displaying a Progressive Web Application by using the Android Browser Helper. The documentation and code indicates that the mobile app only runs properly when the Chrome Browser is 72 or above. The address bar is visible when the Chrome Browser is outdated. I believe I have the option of a Webview-fallback but I prefer not to use Webview as some of the app's functionality is incompatible with Webview.
While testing, when the Chrome Browser is updated on the same device, the trusted web activity runs without any issues.
What options do I have where the address bar isn't visible?
Is the min SDK the only way to set the minimum browser requirements or can I explicitly set a min Chrome Browser version in the Play Console for the app before the user downloads it? (which prompts the user to update the browser before installation)
Thanks in advance!
It's not possible to set a browser version requirement on the Play Console.
Besides falling back to a WebView, or showing the application with the URL bar, the other solution would to block the application from loading and ask the user to update / install a browser that supports Trusted Web Activity.
Problem:
Web page with sms: and mailto: links fail on ios mobile safari browser. A click on the link redirects you to:
Safari cannot open the page because it cannot redirect to locations
starting with "sms:"
or
Safari cannot open the page because it cannot redirect to locations
starting with "mailto:"
These used to work just fine up until around two or three months ago. Now these fail on Apple mobile devices using the Safari browser.
Background:
I create responsive web pages for activity based teams. One of the things we do is provide a team roster. The roster includes links for telephone numbers, SMS text pages and Email.
To keep things simple, we are using simple web pages.
Because of security and privacy concerns, this content is only served via ajax call via node.js server after login. We're using a single node.js Express server to host the website content and manage http/api calls.
Generally a click on the link pushes the mobile device into the appropriate native app for a phone call, SMS text message or email.
This has been working great for a couple of years, on all devices.
Lately we're seeing the problem on iPhones... but...
Here's the really weird part. I've got three teams using this technique.. The failure is only on TWO of the three teams. SMS link works just fine there.
The "tel:" link works fine on all devices.
The failures only occur on two of the three sites for sms: and mailto: on the iphone. Things still work just fine on Android devices, on Windows and on MacOS. The problem is Apple mobile devices.
The two sites that have the failures are Progressive Web Apps, with a manifest.json file and service_worker.js. The site that works fine has neither of those. When I remove the manifest, and turn off the service worker there is no improvement.
All three sites hosted via App engine at Google Cloud. The two sites that fail are only using web_app.appspot.com addressing. The site that functions well is using a real URL, pointing to the app engine location.
Typical Code:
<li>
<div class="userName">Jane Doe</div>
<div class="phoneNumber">321-555-1234</div>
<div class="sms"><img src="../images/crosstxt-icon.jpg"></div>
<div class="email"><img src="../images/email-icon.png"></div>
</li>
I wonder if this will show the issue, if you open this up in the browser of your Apple mobile device:
Click here to create a SMS message.
<br>
Click here to create an email message.
Apparently that's a fail. You don't even get to see the run snippet button on my mobile device.
Testing, more testing...
I just figured out... if I save the site to my mobile device homepage, such that an icon is added to home screen and in display mode, you can NOT see the top URL address bar, nor the Safari options bar on the bottom then the SMS: will fail. If you just open the address in Safari, but don't save the file, then it will work great.
Again, when I'm in Apple Web Application mode, the SMS link fails.
One hack... open the site via Safari mobile browser on the iphone. Save the site to Home Page. Verify the Icon is on the mobile phone. Go to Settings --> Safari --> Advanced --> Website Data, then Delete the site by sliding the content left. Cache storage is clean, but the Icon remains on the mobile screen. Use the Icon to aid in login, but don't save the site again. Note the URL line is visible. SMS will work.
Still testing here...
I tried to build a simple example to show the issue. I was totally unable to get the sample to fail with the error messages above. For reference the test site is here. The test source code is here.
I'm suspecting that the issue revolves around the fact that the two sites in question are both located at a subdomain site. (mywebapp.appspot.com) When the manifest includes all "valid" content the site does appear as a ios Apple Web app without visible URL line... but whenever I'm in that mode, SMS links are a total fail.
With that said, you can control the storage mode via <meta name="apple-mobile-web-app-capable" content="yes"> .
During my testing, I also noticed that whenever the manifest.json file contains // comment marks anywhere the file is ignored by Safari. Normally // comments are not allowed in a .json file, but according the MSN source, they are fine in a manifest.json file.
The choice is
a bit ugly and functional, or
pretty and non-functional
Currently I'm running <meta name="apple-mobile-web-app-capable" content="no">... I get the advantage of a custom icon on the home screen, even though the web app is still obviously inside a mobile browser with top/bottom info lines visible, sigh.
I am experiencing an issue with opening a Microsoft Office Document, using IT Hit WebDAV AJAX library, in latest Chrome 39.0. running on Windows OS. It is a sporadic issue that occurs only in Chrome, and it happens when one opens a document multiple times. Word instance won't start, the page freezes and browser becomes unresponsive, and Chrome suggests killing the page. The only solution is restarting the browser, which solves the issue.
I have tried opening a document in Chrome on Mac OS X, and it is working fine. So are Mozilla and Safari on all operating systems. It seems to be a Chrome + Windows issue only.
Has anyone experienced this issue and is there a fix?
The Microsoft Office plug-in that opens the document displays a warning popup "Some files can harm your computer.", which is a modeless dialog:
If you quickly click on a link that opens the document more than one time the dialog will hide behind the main web browser window. As a result the web browser window is blocked.
You need to switch to that dialog and confirm or reject document opening, otherwise after some time Chrome will ask you if to kill the page or wait.
Note that there is no way to avoid that dialog, this is a built-in MS Office functionality as far as I know.
Chrome will only work good with ITHitWebDAV if the user has got Office 2013 or superior.
Google is blocking all Java applets and NPAPIs now, so good luck with that. I just detect the browser of the user that wants to edit a document, and if it's chrome, I warn him to change to another browser like Firefox with a modal, and that's all.
Very poor support between Chrome and ITHitWebDAV, and no much you can do about it.
I made an offline webapp.
Used application cache and all the resources are added in .appcache file.
I have also added meta tag suggested by apple.
<meta name="apple-mobile-web-app-capable" content="yes" />
When I add it to home screen, it is added & opening in full screen mode.
While all the resources are cached by browser and I am getting no cache update request on reload.
But I try to open webapp while I am offline first time, it is giving me alert "Could not be opened because it could not connect to the server".
By the all the resource of app is already cached by browser still getting this error first time.
But If I open webapp first time while I am online, it is caching all the resources & then second time app is working fine even in offline mode.
Thanks Guys.
When you add to homescreen that is the first time only a reference is added, think of it like a bookmark no content gets downloaded. That only happens after you open it for the first time. Seeing the web app in safari & adding to homescreen does not count since apple seems to maintain the data separately for apps added to homescreen via safari.
The Browser is a different app to the one which runs home screen web app.
I got caught the same way with my offline web app, to debug you change the settings in safari but the actual cache is different, the executable running the home screen app is different, it has several safari functions missing - google uiwebview and wkwebview
I don't know what is currently used for the user agent string, but they used to be different for browser based and home screen based back in ios7