nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

"Aw Snap" application crash when using multiple dashboards in Experience Builder

Brian_McLeer

This post pertains to Experience Builder on ArcGIS Enterprise (11.2) and ArcGIS Experience Builder Developer Edition 1.15.

I have 6 dashboards that are hosted on ArcGIS Portal. In both versions of EB, I have 6 pages, one for each dashboard which contains the Menu and Embed widgets. The Menu widget links to each dashboard, and the Embed widget is the URL from each dashboard on Portal. After using the Experience for a minute or so and switching between various pages on the Menu widget, an error will appear in both Chrome and Edge causing the application to crash. Has anybody had this issue of embedding multiple dashboards and having the browser crash during use? The console logs on browsers did not yield anyresults, and I have exhausted a support case with Ersi on this.

Find more posts tagged with

Accepted answers

All comments

Eric.Shreve@goodyearaz.gov_goodyearaz

@Brian_McLeer & @JeffreyThompson2 can confirm that users are running into this for an EB app built on Enterprise 11.3 when using Google Chrome. The EB App is not complicated. It does have a significant amount of layers, but those are turned off by default, and users turn layers on that are of interest. Guessing it is a browser memory issue and compatibility with EB

TimWestern

One more thing I'll add, because saying its a memory issue, sounds simple, but it could be more complex than that.

If you have custom queries going on, a lot of them asynchronously, and you have a number of methods all firing and grabbing from state, and running till they wait, sometimes, you can get into this situation, where the machine / browser keeps bouncing around, mean while you might be allocating local variables, logging to the console again and again, and this may continue especially, if a method get's called asynchronously from different places, and there is no guard clause to prevent it from changing state.

I had a widget once, that got into just that sort of scenario, and eventually that log file may fill up and dev tools will crash, but even more, sometimes the tabs with EXB get that oh snap error too.

The solution if that is going on is to figure out how to use state to lock down or throttle those calls so that it doesn't keep firing methods over and over again with out chance to return.

I don't know if your hub has anything like that going on, but if you open it up, with F12/dev tools and watch the console, see if messages keep scrolling, if so this could be a sign of either (an infinite loop) or an unpredictible async chain that never quite returns Success. (I am going to guess that maybe your dashboards to not actually, have any custom widgets, in which case there is likely little you can do, but in the off chance you have some custom code running, look for that, and it then comes down to figuring out how to prevent additional firing or infinite async calls)

Brian_McLeer

This morning, I tried a different approach by adding the 6 dashboards to a new Hub site. The dashboard will open in a new tab from the Hub site, but the same results. It seems to be the consensus here that a browser memory issue causes the crash.

TimWestern

Note its not just dashboard tabs that can cause this. If you have users with multiple tabs, multiple browser instances, depending on their hardware specs they could run into this. I've generally only seen this when there are a large number of active tabs. Chrome does have a memory saver mode that can free up memory when tabs go inactive, but that's a double edged sword. I've had workflows or content I was working on, disappear due to inactivity. This is a side effect of those changes.

This may seem like a nothing burger, but I've noticed that certain positions that use browsers are more likely to leave things open in a browser session for long periods of time, and forget to use the website 'save' options. This can be frustrating to both IT folks and users when they try to get a backup of something that was wiped out due to inactivity 😕 (It's the browser, and user behavior in that case, not just dashboards)

Brian_McLeer

Thanks, @JeffreyThompson2, I will look into these options as well.

Jeff.Thompson@arlingtontx.gov_arlingtontx

A couple ideas that might make this design viable.

If you are using Sections, try the Lazy Loading option. This should delay loading a View until it is actually needed.

If you are using Pages, try opening the Page in a New Window. This should spread the memory load over separate tabs and make it easier for Chrome to manage.

Brian_McLeer

Thanks, @JeffreyThompson2, I think the undesirable workaround might be just to have users go to each dashboard individually and not try to have them all in one Experience.

Jeff.Thompson@arlingtontx.gov_arlingtontx

Chrome and Edge are very memory hungry applications. Experience Builder and Dashboards can also be a memory hog. Even more so, if you are using live updating data. I thought you ran out of memory even before I saw the error code.

Join the Conversation

Signed in members can post, follow updates, and more. New here? Register a free account.

Quick Links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.