I’m having an issue where if I change views or pages too quickly I eventually cause the client to crash. I am using Chrome on a desktop in developer mode to see this, but it also crashes on the iPad app as well. I am using one of the latest nightly 8.0.9 builds (maybe from a week ago or so).
The issue seems to stem from these “Received updates for missing view” warnings in the Chrome console. If I switch views or pages too quickly I start getting a lot of these. If I wait for the page/view to fully load before clicking on a new navigation button the amount of warnings is very small and no issues seem to occur, however if I start pressing on navigation buttons quickly in succession then the client basically locks up and looks something like this.
The DevTools console in Chrome looks like this. First picture is before the client crashes - it’s just warnings, but the second picture shows the errors that occur when the client has crashed.
For what it’s worth the issue seems easier to make happen on the iPad (using the app) or a Surface Tablet (using Chrome) compared to my more powerful laptop (using Chrome), but that may be somewhat subjective. Once it is locked up the only way to get out of it is to refresh the page in the browser or app.
At this point I don’t know if there is something we have designed poorly or wrong causing the issue, or if there is a memory/loading issue or bug in Perspective, but the issue is potentially problematic if put in front of an operator that starts pressing buttons quickly and doesn’t know what they are doing.
I don’t know if it’s related or not but in the gateway log I do see these warning messages as well. The timestamps, however, do not match with the errors in the DevTools Console of Chrome, so they didn’t happen at the same time.
This was replicated internally by navigating away from a view while bindings were being evaluated. An internal ticket will get filed for this. But just to make sure we are seeing the same thing, in your “Reusable” view is there a binding on a toggleswitch component that either takes a while to evaluate or evaluates often?
The view is actually called “ToggleSwitch” and its in a folder called Reusable. Sorry for the confusion, but I just wanted to make sure that was clear.
To answer your question, there are quite a few bindings involved in the view. The view itself has roughly 12 bindings - almost all of which are evaluated off of an indirect tag binding. The tag values change infrequently and are likely not changing much when the view is being opened.
Inside of the view there 5 or so objects (labels, images, buttons) that each have 1 to 2 bindings as well. These bindings are more varied - expressions to tags in the tag browser, bindings to view parameters, and bindings to custom data in the view (which are tied to bindings as mentioned above).
That makes sense. Sounds like the same thing we are seeing then. I’ve linked the internal ticket to this forum post so when it gets fixed this thread will be updated.
I don’t know if it is related to the exact issue above, but I actually think the cause of the crashing may be memory usage of Chrome, perhaps related to the other issues. The memory usage appears to constantly climb as I open new pages of my application. I do have a lot of bindings so I’m not sure if that is an issue or not, but it does seem more prone to crashing when I get around 500 MB of memory or over 500 warnings in the console. Sometimes I can go over temporarily, but it seems likely to crash soon after. In regards to the memory, I am able to crash it without getting too many warnings in the DevTools console and that is usually around 500-650 or more MB of memory.
The above was using a desktop 64 bit Windows OS and Chrome install in Developer mode to simulate touch actions. I was also able to test on a touch screen device (also 64 bit Windows and Chrome) and run it without developer mode. I was able to use around 1000-1200MB before having issues
We’re having the same “Maximum call stack size exceeded” and “ui.ErrorBoundary” errors. Only difference here is that it happens when opening a view (even on a fresh session), instead of when navigating away from a view.
For us it was happening on all of our views that had an indirect tag binding. I was able to fix some of the views by changing the indirect binding to a tag read that fired on a timer. but there are still a few views that experience the issue, even with the tag reads on a timer.
I just did a test where I only placed the affected view as an embedded view within another view:
The bindings will flicker on and off until it either gives a component error, freezes chrome, or resolves to the correct values after 20 or 30 seconds.
The embedded view holds the following objects:
Pump, Label, RunStatus.Label, and HOA.Label all have Tag bindings for a total of 5 tag bindings.
Root has a binding to a param
Valve references one of the Tag bindings on Pump
We’re having the same “Maximum call stack size exceeded” and “ui.ErrorBoundary” errors. Only difference here is that it happens when opening a view (even on a fresh session), instead of when navigating away from a view.
It actually happens when I open the view too, but it seems more prevalent when switching pages/views quickly. Sounds like that could be due to bindings not being updated in time.
I don't have a flex repeater either, but there are lots of embedded views with bindings of all different types.
Can’t really provide a timeline if we haven’t fixed the problem yet
It’s literally at the top of the pile, and there’s a decent chance we’ll hold the release train for 8.0.10 for this bug. That’s as high priority as it gets. There’s not really anything else we can promise in the meantime.
This ticket was resolved as fixed. If you are continuing to see this, we’ll need detailed instructions on how to replicate it. Or even better, a minimal project that demonstrates this.
