On IOS 10 within safari (and chrome) websocket connections are dropping, I can see it making the initial connection on the server side, but then doesn't keep it alive.
Before updating to IOS 10 everything was working correctly, it also works fine in safari on OSX.
There are also no signs of error in the JS console my initial thoughts are issues with the Content-Security-Policy but I have still come to no avail.
Related
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.
My websocket connection works:
When testing on localhost on Desktop Chrome, Desktop Safari, and iOS
When testing on production on Desktop Chrome and iOS.
It DOES NOT work:
When testing on production on Desktop Safari
There are no console errors in the browser. I can see the websocket is created, but it never fires "open" event on Desktop Safari. On the server side, the connection comes through fine everywhere other than from Desktop Safari, where I don't see anything come in.
The websocket is on the exact domain as the origin, and both are using secure connection (https/wss)
There are a lot of moving parts on production (e.g. load balancer). I've looked at and configured things like "stickiness" and TLS versions on each layer in production.
Again, it works most places.
I'm thinking there must be something like TLS, CORS, etc that I'm not fulling understanding that is causing the breakdown.
This is what happens on iOS (and about the same in Chrome desktop, etc):
This is what happens in Desktop Safari on Mac:
Well. After many hours of spinning my wheels I solved it:
There is a setting in AWS Load Balancer attributes called "Client port preservation". Once I checked this, websockets started to flow from Desktop Safari:
I'm working on establishing a RTC connection between a Chrome/ff client and Edge client. I'm using the most up to date adapter.js shim. I have everything working without a hiccup except for the following two:
1) The call can only be initiated by the Edge user, otherwise the transfer of sdp information doesn't complete.
2) When initiated by Edge user, the full exchange happens, but remote videos can't be seen, which I think I've narrowed down to a discrepancy in stream ids between the two clients.
Chrome local streamid: "aPshOXkbsPHswpajCqzaJcLowZzSHZr6QrPD"
Edge local streamid: "89077962-9A1B-47B9-8754-7B80FAAC82DF"
Chrome remote streamid (Edge local): "89077962-9A1B-47B9-8754-7B80FAAC82DF"
Edge remote streamid (should be chrome local): "3750A59D-7E90-450A-96BB-63EED7D564C3"
So it seems that Chrome has an issue with the id of the Edge stream, and then for whatever reason Edge is interpreting the Chrome stream and/or its id.
One ancilliary issue that I've noticed with Edge is that when the success function fires from the navigator.mediaDevices.getUserMedia function, the video camera starts up, but then immediately shuts down. I have to enable it afterwards through javascript and then obtain stream ids, otherwise chrome/other client won't even get correct stream information of edge's running stream.
I haven't submitted an issue on the webrtc-adapter github repo yet, I'm firstly curious if anyone has any tips on how to tackle this issue. All the browsers are fully up to date. The clients are communicating from debian wheezy and Windows 10 (pro, creator's update edition). Works fine between the two machines if any combination of chrome and firefox are used.
It is written here that the push notifications will work even if the browser is closed, but I tested it and it is not the case. I receive push-notifications only if the browser is open (doesnt matter if the particular webpage is open or not).
I tested this on chrome for Desktop & chrome for Android (after updating to latest version).
my question is :- For push notifications to work should the browser be open?
Note:- I used this for testing.
According to Can I Use, Chrome and Firefox desktop browsers require the browser to be running for receiving push notifications; mobile browsers typically don't.
Open Settings (in chrome)
Do the following:
> advanced
> system >
"continue running background apps when chrome is closed"
>enable
On desktop, browsers need a process running. For example on Mac OS X the browser can have no window open but if you look at the dock, the light underneath icon can be glowing (meaning it has a process running). In the scenario you should receive push messages.
If the browser was completely quit, then push messages won't get through.
The same applies to windows and Linux.
On android you should be receiving the messages regardless of whether the browser is open or not. This is in part (as far as I know) to the fact that android manages it's connection to the push service rather than the browser, so it'll receive messages whenever possible.
The messages should (eventually) get through even if they are sent while the browser is closed, or the device is offline, etc. (And this works for me using https://gauntface.github.io/simple-push-demo/ and other tests.)
I've worked on demo to provide push notifications on Google Chrome and Firefox. Demo -> https://twitter.com/d_danailov/status/1163824171480166400
If someone has a question could ping me on twitter.
The public URL: https://push-notifications-ddanailov.firebaseapp.com/
Repo: https://github.com/dimitardanailov/push-notifications
On desktop the browser needs to be running since that is the process that receives the push messages. Some extensions, like hangouts force the browser to keep running even when the last tab is closed so for users with one such extension installed push will work all the time.
On Android, the browser does not need to be running since the entity in charge of receiving the messages is baked into Google Play Services.
The Chrome team is working on the desktop issue in https://bugs.chromium.org/p/chromium/issues/detail?id=402456
It is possible to write Chrome extension where background script can run if Chrome is allowed to run in the background (configurable in settings). It can also use GCM.
EDIT:
For service worker to run in the background even if no tab or window is opened there must be at least one Chrome extension with background permissions installed and Chrome must be allowed to run apps in background. Tested on Linux.
Yes, the other users are right and there is no way to receive them on Windows if the browser is closed unless the browser is running in the background, which some Chrome Apps and Extensions can force. I ran into this recently and found this extension, which I believe may help. It keeps the browser running in the background even if the windows are closed but does not do anything besides that (it is open source and presumably the version uploaded to the Chrome Store matches that version)
https://chrome.google.com/webstore/detail/lightning-reopen/ahphokgmcecbjeipkfkamcdmemghkaph
I'm not even sure where to begin. Page loads fine on my 5, but not my 4S. Instead it crashes the browser to the home screen.
Without sharing the specific URL, can you point me in the right direction to debug this?
There are no discernible errors in Firebug or other debugging tools on my computer.
You should be seeing a crash report in Xcode organizer and an exception on the command line. Since this is an Apple app you should report this as a Radar.
Does your 5 have a newer version of safari?
Use the iOS simulator if you have it, and then try running with different versions of safari, you can get a log output from it, especially if you are using dashcode, otherwise I think it is in the system logger. That is, if you have a Mac.