I did a lot of search, found some topics like Detect that the Internet connection is offline? but they don't solve my problem.
When I took a look at Google Doc(maybe Gmail use the same way) product, its Internet connectivity checker looks great and almost got notified in real time once you turned off your WiFi.
If you turn on Chrome's Network Monitor, there are http requests: https://0.docs.google.com/document/d/1muWJEAPZU2meqlBg4_69osnscaM1GpxkOK--H7r-f44/bind?id=... and restarts every minutes(55 seconds around)
When you turn off the WiFi, the long polling request get interrupted by ERR_NETWORK_CHANGED.
I try to implement something like this on my own machine, but my long polling request never got interrupted or exception (I use tornado web framework and google chrome)
Is there anyone can show me the magic part that how Google doc checks its connectivity?
Related
I'm writing an application that first tries to open a WebSocket connection (to make sure no others are open; address collision checking) before firing off a custom protocol that will launch a one-time WebSocket server with the address that the browser tells it. All communication is done over localhost and some arbitrary port number, say 3000. I'm not doing anything special, just attempting to open a WebSocket:
var socket = new WebSocket("ws://localhost:3000/MyApp/");
socket.onclose = function(e) { console.error(e); }
When testing in Chrome, the WebSocket will actually stay in the CONNECTING state for a little bit, which is ideal, since it gives us some time to actually launch the app through the custom protocol. But in Firefox, the WebSocket immediately closes with code 1006 and I can't figure out why.
I've tried changing the about:config network.websocket.timeout.open setting to be 1000 (from 20), but that doesn't help. I've also found this related post: Websockets - chrome and firefox differences?. That hasn't lead me to finding an answer, either.
What am I missing?
Update 11/16/21
I'm using the Dev Tools in Chrome and FF to check out the requests. The weird thing is that Chrome is actually sending a request header as you'd expect, but in FF, the request is completely empty (0 Bytes). Maybe this is a problem with FF not supporting debugging native WebSockets (no wrapper libraries in use)? Is there some FF setting that nixes the request? But even more confusing is that the browser would hit the close event without ever hitting the open event.
Update 11/17/21
I realize that maybe this has something to do with launching a Custom Protocol Handler? I noticed that it will wait a second to try and connect to a web server if no CPH is launched, but then when I do launch a CPH, that is when it immediately closes the WebSocket. The CPH is launched via a link targeting "_parent".
It looks like the custom protocol is causing FF to stop trying to connect early. I created an anchor element, <a>, in the JS code and called "click()" on it after constructing it. No matter what target I gave it (e.g. _self), it would cause the connection attempt to stop.
So long story short, initiating a link, whether it be a a.click, window.open, or location.replace, will cause Firefox to nix any currently polling WebSockets!
The workaround is to just use an iframe to launch the custom protocol.
I would like to know. Is there any option to generate random network errors for testing of js code? I am trying to implement some error handling during the upload of files to the PHP server but "unfortunately", my internet is rather stable at home + I do it in LAN. I was trying to use a VPN switch, but it switches almost instantly, without network disruption (or at least it seems that way) and even if it worked, I do not feel like using that solution because of that frustrating routine that comes with it...
Thanks!
The Chrome inspector's Network tab has options for, among other things,
throttling your connection
blocking requests
and simulating offline mode for your tab (which might do the trick if you hit it during a request).
I work on a web application which gets push type updates from a rest server using a long polling technique.
It runs setTimeout() which executes a function which does a xhr GET request with a timeout of 120 seconds. It also sends the server a special "Accept-Wait" header of 60 seconds, which tells the server when to reply with a 200 and no data for the client. Then the client repeats this setTimeout. This continues forever while the client is "logged in" to the server.
I have a user using Chrome (he is only able to use Chrome so I haven't verified if this is reproducible in other browsers since no one else can reproduce this problem) who when he minimizes, the GET requests start timing out. This looks to my longpoller like the server is down.
I have enabled debug on the rest server and confirmed that it has nothing from this user for 2mins (seeming to indicate the GET requests aren't getting out of the browser).
I have also watched in the Chrome terminal (F12) "network" tab, that the requests are "cancelling" at 2mins, indicating they are timing out.
This problem also reproduces when using "localhost" which I think rules out network issues.
How can I get more information about Chrome regarding why it isn't letting http traffic out for this user?
Thanks
If this issue happens only in google chrome, maybe it is discarding your tab, you can prevent it by disabling a flag, type the following url on adress bar and see if it is enabled:
chrome://flags/#automatic-tab-discarding
I've been creating a site that's meant to work on all browsers, and connects to a nodejs server through a proxy (meaning, the client connects to the server through a proxy) using websockets.
The site works fine on all browsers, but I've noticed some strange behavior on IE. The more the client browsed through the site, and as a result, opened more websockets, the slower the tab the client was browsing through became. Eventually, the tab would stop responding entirely and had to be shut down entirely because it'd stop responding.
I tried to whittle the problem down as much as I could, and eventually noticed that when your browser uses an explicit proxy, and has websockets, after a set amount of connections (around 25) the tab you're using will stop being able to connect to the server, and may stop working altogether. It's easy to reproduce this using the following steps:
Take the example page from here and create an html page
Download fiddler and use it as your proxy
Browse to the example page that you created and keep refreshing your tab. You should notice a slowness, until an eventual stop
It's worth noting that without a proxy, the tab will not end up dying like this.
Has anyone else encountered this issue? If so, is there any fix to this, aside from changing the architecture?
Thanks a lot
When I am creating google map on hybrid app and network suddenly disconnet, the google map show nothing after network has been reconnected. I got a error message as below and try to reload google map javascript again. Sometimes the map was created success but always failed. Is there any solution for this problem?
GET http://maps.gstatic.com/cat_js/intl/zh_tw/mapfiles/api-3/16/2/%7Bcommon,map%7D.js
net::ERR_PROXY_CONNECTION_FAILED %7Bmain,places%7D.js:10
GET http://maps.gstatic.com/cat_js/intl/zh_tw/mapfiles/api-3/16/2/%7Butil,stats%7D.js
net::ERR_PROXY_CONNECTION_FAILED %7Bmain,places%7D.js:10
watchPositionError 0
I know it can be annoying to think about, but at some point you just have to put it out of your head, and an important thing to take note of is sometimes the user will enter into situations where your app doesn't work exactly as you want it to, and it's out of your control, for example if the user disconnects the internet.
Another example of this would be if the user doesn't support cookies, or if they don't support javascript. As a developer, you won't always be working with the resources you need to build software for every person on every platform and in every scenario. Sure google has the ability to handle internet disconnect/reconnect in google drive, syncing up to the server when a connection is re-established, and Twitter has a mobile site that supports users who don't have javascript. As a developer you will have to make a judgement call on what is and what isn't a must-have feature. I'm guessing this isn't a must-have feature.