Samsung S4 - Default browser not loading webpage - javascript

We have developed a webpage which uses ssl hence https:// and it loads fine on all (*the ones we have tested so far) just fine...
however when attempting to load on the Samsung Galaxy S4 - it just shows "This web page is not available"
This is Samungs default browser (which apparently when conducting browser checks still shows as Chrome 18) - loading the site on the chrome browser (which comes installed by default) works fine.
So the question is what do we need to do for the device to load the web page.

Have you freshly installed SSL for that website?
When you install a SSL on your website (static IP from the server changes to the new IP in which you have installed SSL) So just wait for 24-48 hrs(Max) as it needs to propagate in all the dns servers. It is also a good idea in such cases to clear up your browser’s cache and try visiting your website

Related

Uncaught TypeError: navigator.getBattery is not a function

I'm developping a website which is meant to be used on mobile devices using Google Chrome, the purpose is to list information such as time (hh:mm) and battery level.
I saw the Battery Web API but I'm experiencing a strange error:
click to see the chrome error
Here is the code I used in order to get the battery level:
navigator.getBattery().then(function (battery) {
console.log(Math.round(battery.level * 100))
});
I had the error yesterday, without changing any line of code, it is working today on my tablet (chrome version: 103), but I tested on another tablet (Samsung Galaxy TAB A7 LITE, Chrome version: 103) and I encounter the error, I restarted several times the devices, inspected pages using the devtools connected by cable to my laptop, but I can't solve this error.
I saw a topic having the same error but he was developing a web worker it is not the same context as I.
No matter when I'm calling the navigator.getBattery() if the error appeared in the beginning it will stay undefined later, so it is not a problem of timing to call it (I even bound it to the body.onload but it didn't work).
I thought it could be authorization issues on system information but there's nothing refering to the battery which is not authorized in the application settings of Chrome.
Any help is welcome :D
I found out where my error was coming from.
It is a problem of HTTPS, my testing environment is configured behind a NGINX HTTP Server, which serves HTTP and HTTPS version of my application in order to use a single certificate for every of my projects, Chrome on my laptop prefix URLs I'm accessing with https:// and it is hidden in the navbar, but it is not the case on Chrome tablet or mobile, I thought I was consulting the HTTPS version but it was HTTP, and Battery Web API isn't accessible on HTTP websites, it is required to have a secure connection using HTTPS and certificates. It has nothing to do with version number since Battery Web API is fully supported since Chrome version 38 according to MDN Documentation.

How to redirect webServer to Chrome browser by trigger- Javascript

I'm creating one product(webServer), That product provides wifi Hotpot. If you connect that Hotspot, webServer will open automatically on the default browser. In some Mobile, It opens on WEB UI browser(it's not installed browser). Our webServer works better in Google Chrome or any other mainstream browser, so if there is any possibility to redirect to Chrome browser by any trigger or else any possibility to open server only on Chrome browser?
It's not possible to open a specific browser of a system. The reason is that you are requesting the system to handle a scheme (like http://, https://, ftp:// or file://) and the system will decide how to handle this . For http:// and https:// it's (most of the time) the browser defined by the user.
In addition, Chrome might not be available on every device requesting your server.

Failed to load response data with Chrome on HTTPs

I have some troubles to start my WebApp with Chrome (not always).
My webApp is a simple Javascript App and it's loaded using HTTPs. The server providing the WebApp resources is using a self signed certificate that is not trusted by Chrome (same for Firefox...).
When a user starts for the first time the WebApp (or after cleaning the Chrome's cache) using an URL like https://mywebapp:8443/ui the user gets a message that the website is not trusted (ERR_CERT_AUTHORITY_INVALID) but the user can continue (it's the expected behavior).
Next, there's the issue: Chrome starts loading my webApp by getting the index.html and then the .css but it's unable to get the .js that contains the Javascript code of my webApp.
In the Chrome Development tool, I can see the response of the HTTPs request to get the .js file is "Failed to load response data".
I don't understand why there's this error with Chrome (it never happens with Firefox).
Next, if I reload the page in Chrome, the WebApp is successfully loaded and displayed.
I can reproduce this issue when I'm cleaning the cache in Chrome. If I'm not cleaning the cache the WebApp continues to work even after a Chrome restart.
Can it be due to the self signed certificates? What can be the reason of this issue during the first start? Why it happens only with Chrome?
Thanks for your help,
I guess it's due to using a self signed certificate,the newest Chrome Brower don't allowd trust self signed certificate,so your own certificate is not trust by chrome!
You can into chrome://net-internals/#hsts in brower address blank,then delete 'localhost' in HSTS list.
I was wrong, the issue was also appearing in Firefox.
I have found the root cause, it was due to the backend that uses a Kong cluster between the WebApp running in the web browser and the tomcat server that is located behind Kong.
An important things is that I'm also working in a DC/OS environment and between the WebApp and the Kong there's a marathon-LB !
Ok, the issue is the marathon-LB is dispatching the requests from the WebBrowser to one of the Kong from the cluster. Each Kong has its own self-signed certificate and as a consequence, the web browser gets responses from the same IP# signed with different certificates (since each request is managed by a different Kong).
When I configure the Kong cluster with only one instance everything work well because it's always the same Kong that is responding and all requests are signed with the same certificate.
The solution is to configure the marathon-LB with a certificate and then only this one will be forwarded to the WebBrowser instead of the Kong certificate.

Android Native/Stock/Default Browser Won't load my React Web App

So my react web application loads perfectly fine on Android Chrome Browser, and other browsers such as UC Browser, Safari on iOS.
However, recently we found that the web application loads blank page when opened using Android Native/Stock/Default Browser ( The blue globe icon ) found on any Samsung / Lenovo devices.
I was able to use weinre / ngrok to attach web debugger, but I was not able to find any errors. The browser would just stop requesting for more static assets and stop doing anything.
I ran another test for my internal web application which is also a react web app (same config), and it loads fine on Android Native/Stock/Default Browser. I'm looking for clue as to what may cause this browser to stop requesting from the webserver...
Thx

Javascript web application does not show certificate not trusted in Chrome

I have an application using https to do a jsonp call on my server which is self signed.
If I use the corresponding url in the Chrome address bar, then a warning is showing with 'The site's security certificate is not trusted!'. There the user can proceed anyway.
Now in my web application, there is no such warning and the request just remains pending indefinitely. I can see that in Developer tools. I would expect having something showing on chrome similar to the above behavior.
Chrome version is currently 25.0.1364.172.
Is this normal?
What should I do to address this problem?
Thanks!
Unfortunately this is normal. Try to browse via firefox, backup the Certificate and install it in Chrome again.

Categories

Resources