When you're developing a web application, you need to take browser compatibility issues into account. I encountered a problem with an Android in-app browser that wasn't tested during development but manifested in production, leading to thousands of failed transactions. There were no clear logs to pinpoint the root cause, so it took me some time to figure it out. I'm documenting this issue here in hopes of saving you some future troubleshooting time.
When your end-users access your web app through a third-party Android in-app browser, you have no control over this
webView as it is provided by the third party. If the
false, you're essentially at a dead-end. If you're lucky enough for the frontend code to still load, note that the
setDomStorageEnabled setting is
false by default. If you refer to the official documentation:
This boolean flag sets whether the DOM storage API is enabled or not. The default value is false, which means the WebView will disable the DOM storage API. This setting can halt your code execution when it tries to access the
localStorage object in the browser.
The solution is simple: add a condition to check whether
localStorage is available before proceeding with the code. This issue doesn't produce a meaningful error message, making troubleshooting particularly challenging, especially when you have to simulate the problem within an Android in-app browser.
One tip for replicating the issue is to download the following tool:
This app is quite useful, as it allows you to view console logs within the Android in-app browser.
Another tip for troubleshooting via server logs is to examine the request header's User-Agent Strings. You can identify WebView requests by looking for the
wv field in the example header below:
Mozilla/5.0 (Linux; Android 5.1.1; Nexus 5 Build/LMY48B; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/43.0.2357.65 Mobile Safari/537.36
I hope this article helps you and saves you time dealing with this particular caveat.