I have an Angular front-end with a PHP/MySQL backend. The application runs reliably at a number of client installations, both wired and wireless, cable and DSL, Chrome and Firefox. One user, however, can use the app for anywhere from 3-4 to 20 minutes or more, then some browser events stop firing - usually ng-blur and/or ng-change.
I've looked through the code repeatedly, to no avail. All the other users are fine. This user has attempted the app on 2 different Dell laptops using Win7 and Chrome, both wired and wireless, and experiences a similar issue each time.
Can anyone suggest a reason for this erratic behavior, like browser add-ins or network security programs that interfere with browser operation?
I have located the problem. After checking with my users, I found that the one experiencing the problem was using AVG antivirus, all the rest were using McAfee or Norton.
I installed AVG on an older machine, and within a couple of minutes was seeing the same sort of problems. I'm considering this "solved".
Related
Context
A game shipped as a progressive web app which has timers (setTimeout, setInterval) and websocket connections to get real-time communication.
What is happening
Everything is fine as long as the user stays in the app. But when the user goes to another tab, or another app or turns off the screen (in case of mobile), it becomes a "hellish unknown world".
Websockets may or may not become "paused" or "turned off"
Timers look like they are being throttled or debounced.
This behaviour seems to depend on browsers and platform and, maybe, even depend on the particular user behaviour. I guess browsers and OS have their own lifecycle / mechanisms to save battery and/or computation.
When the user comes back, the app is in an unknown state and I am struggling to restore the state properly.
Regarding websockets I have auto-reconnection with socket.io and reconnecting-websocket but it's not enough to solve everything.
Looking for answers
What are the "lifecycles" of the different browsers regarding these? Is this documented? When do they decide to turn off and throttle?
What do they do exactly to websockets? Browsers just disconnect them?
What do they do exactly to timers? They throttle them or debounce them or something else?
What happens to javascript execution in general? Paused / destroyed / throttled?
Is there a way to hook into some kind of browser lifecycle event when it's going to turn things off? The only thing I could find might be the visibility API
Is there a way to artificially reproduce this behaviour to be able to test solutions? It's especially hard on desktop. Websockets can't be turned off and chromium developers don't seem in a hurry to help an issue from 2014(!): websockets not included when using connection throttling
Regardless of the above, is there a pragmatic cross-browser solution to detect / solve this problem? (for example from experience, Firefox on desktop seems to behave completely different compared to Chrome, and an iPhone will disconnect far more often than an Android)
Related Links
Safari dropping web socket connection due to inactivity when page not in focus
Not exactly sure, but you could use service workers. As much as I know, they run in background even if your tab is not opened and get terminated if your tab closes.
Btw. lifecycles of browser tabs seem to be different on every browser, since every browser handles it different. From what I see the browser can freeze tabs if it needs more memory for other things.
Here is the docs from Chrome.
I remembered that there are some events, like onload that tell you if a user has left or reopened the tab. You could use these event to reconnect etc..
I would give different advice regarding how to design your app. From what I understand your intention is to add more logic in order to understand if the user is no longer active in the browser. This entails a different problem which is browser specifics to implement that logic. With that in mind, I would instead invest in have better error handling, both in the server and client.
Errors won't be browser-specific. Handling those will make your app more resilient and agnostic to browser changes, that could eventually change, let's say, the way they hibernate a tab, any other feature that a vendor might implement in the future.
This is an idea that you can find in services architecture, but the same pattern applies to any web-app. You might want to look for Design-for-Fail concepts:
Complexity makes it infeasible to assume robustness on the part of the systems upon which one relies. Instead, one needs to design systems and applications at any given layer in the IT stack-based to assume the possibility of failure at lower levels. Design-for-fail necessitates thinking about fault tolerance at all layers. No longer can application developers confine themselves to thinking about functionality.
https://www.oreilly.com/library/view/designing-delivery/9781491903742/ch04.html
I'm building a React Native app (currently iOS only) and I found a very nasty bug that only manifests itself when 1.) running on a real device, and 2.) running without Chrome debugging. (Ouch, right?)
I'm using react-native-router-flux with tabs and when I tap on a button that loads a new tab route (Actions.tabRouteName), the screen goes blank. As I said, it works fine in the simulator, and also, on the device when I enable Chrome debugging.
Other things I tried: running on another device, reloading JS, rebuilding app in Xcode.
Any reason the behavior would be different in these different run cases?
Thank you.
Update: This appears to have something to do with animations and route switching. I posted more details in this Github issue. I also found anecdotal support for the idea that other people are encountering similar issues with debugging in this Github issue.
Any reason the behavior would be different in these different run cases?
It's because when you use remote debugging in Chrome, it practically runs the RN app in the browser (it then uses the V8 JavaScript engine) and communicates with the simulator (or device) through WebSockets. When it runs without remote debugging enabled, it uses JavaScript Core. There are many differences between these environments and these can cause inconsistencies, so don't rely much on running your app only with JS debugging enabled, it can give you false errors or hide errors that would actually cause problems on a real device.
Question:
What is the best way to communicate between separate Google Chrome rendering processes (tabs) without the use of a web-server?
Background:
I am writing a large application and recently I decided to try and migrate the whole thing to the browser. Due to where I work this is Google Chrome. Previous the application consisted of a c++ based (Qt) webserver / calculation engine and the browser was only used for the GUI. Now I have moved the calculation engine to javascript and I run it in the browser.
The problem is that the GUI is slightly unstable. It will often stay running for about 12 hours but then crash with an "Aw Snap" error. Before I wasn't worried because it was a simple matter of refreshing the page. Now when the GUI crashes because it is running in the same process as the calculation engine, that crashes also.
Details:
The calculation engine is now a web-page that spawns a number of web-workers. It also opens the GUI (a separate webpage) as a popup window and communicates to it using PostMessage.
The GUI typically needs to read ~ 500 floating point numbers / second (sent as JSON) from the calculation engine and write back ~ 5 numbers / second.
Yesterday I got excited because I discovered the SharedWorker API which I thought would accomplish was I wanted. Today however, I learned that recently modifications were made to Chrome so the SharedWorker actually runs in the same process as the attached tabs and it actually forces all the tabs attached to it into one process. Apparently it didn't used to do this. Does anyone know if there are any browser flags that I can set to revert to the old behavior?
I also have read a little bit about ServiceWorkers and other new APIs such as WebRTC. I have also played around with the storage APIs and thought that maybe they could be used to get two separate processes (tabs) to communicate at the rates that I need.
I want a solution that will work locally (using switches like --allow-file-access-from-files) and that doesn't require plugin installation (since even local plugins are blocked where I work).
NOTE: I saw some other similar questions but they didn't specifically address the need for there to be separate processes (only separate tabs)
Well, it looks like I figured out the answer already. The problem turned out to be how I was trying to open the GUI window.
I had a link on the calculation engine that the user clicked on to open the window:
Open GUI
However, it turns out that adding rel="noreferrer" will cause chrome to open the window in a new process.
Open GUI in new process
After I figured this out, the SharedWorker began to function as I had expected and I was able to keep by engine tab running even when the GUI tab crashed.
For a while I've been trying to run a JavaScript CPU profile of some applications I've developed, but everytime I start running the JavaScript CPU profiler in Chrome Dev tools, the application will stop responding at all (same as the profiler).
However, I noticed that this is not specific to my application, since I've been able to reproduce the same problem in other popular applications like Travis-CI.
I've been suspecting of extensions and plugins, but running without them doesn't seem to make a different -- the problem persists.
I've tested simpler apps with the same technology (the To-Do MVC example built in EmberJS) and that profile works just as fine.
I'm currently using Chrome 40.0.2214.111 m (64-bit).
Any idea on what the problem may be?
Update: I've tested both under incognito and guest browser mode. I thought the guest browser made a difference because I was able to profile my application once without problems. However, trying that again proved that the problem still persists.
Furthermore, I've found that the freezing time does not seem to be related with the application itself. Sometimes it'll hang when I focus an element, sometimes when I move around, some other times when I am in the middle of writing into a textbox. There seems to be nothing specific about the functionality of the app that's triggering this.
I've also tried disabling most extensions, without luck. I'll try disabling plugins as well and run as bare of a Chrome as possible.
Update 2: I've disabled all plugins and extensions completely, but the problem persists. I've also let the session go on to see if it eventually recovers. After around 2 hours, it was in the same situation. No bigger CPU consumption nor memory consumption, and other Chrome instances or tabs worked perfectly fine. I was able to close the developer tools but not interact with the original page anymore.
Update 3: I've just upgraded to Chrome 41 because it has been released in the stable branch, and I know it does include a few more things in the profiling section. I tried again and it didn't seem to make any difference.
which is all the user, I'm having to remote debug can tell me... Since I'm also without a device to test for the next couple of days, I'm pretty much in the dark.
The application is a web-app written in javascript/jQuery Mobile and working fine on iPad1+2 and iOS3+4. When the user was instructed, the system worked without problems on his iPad
Now he is stuck on the first page and sometimes "nothing happens", but even when the page works he cannot even log into the system.
Question:
Since the application worked fine the first time and I have read there are some new caching mechanisms in iOS, I suspect it could be related to this. However, there is no place to go online when looking for things to be aware of when using script heavy web applications on iOS6.
So, what pitfalls do I have to be aware of when upgrading an application to iOS6?