Fix Case Event List Item and Event Form List Item templates from rerendering constantly creating DOM Nodes leak

[rjcorwin]

If you load up a case with a couple of events, you'll notice about every 5 seconds the Case Event List Item and Event Form List rerender resulting in an ever growing DOM nodes that take up memory. Note the flashing parts of the DOM here indicating a change in the DOM... When nothing has actually changed in the Angular component's data.

I placed a debugger statement in those components, the function to actually render is not getting called. It's just the Angular template recreating those things at a constant interval. Those things created are actually template variables of unsanitized HTML. I imagine this recreation would also be true for text strings. Perhaps Angular is thrashing on HTML that when it renders changes itself and it keeps trying t change it back to the original value?

[rjcorwin]

We might be able to prevent this by disabling change detection on those Angular components with this strategy. However, that might be too high level, this is that particular template variables going through pipes keep rerendering. That unsanitizeHTML pipe might be the problem because it keeps piping out at this interval.

[rjcorwin]

A note on the implications of this leak.. Leaving the app open on a list of event for a half hour results in 100% CPU usage and 1.5 million DOM Nodes. On a Samsung tablet, trying to navigate to an event takes about a minute or two.

[mfinholt]

Amazing Sleuthing, @rjsteinert !

[rjcorwin]

Thanks @mfinholt!

Turning off Angular's change detection is doing the trick! No more flashing changes in the DOM there.

However DOM Nodes are still going up because of another component we need to turn off change detection on... The Case Component handling that description of the case.

Meanwhile over on the list of Event Forms, the change detection seems to be getting more aggressive. It's flashing multiple times a second as opposed to the every 5 seconds we saw before.

[rjcorwin]

With manual change detection implemented, all is quiet on the Case page now on PWA with the recommended amount of DOM nodes for a page and 0 CPU usage.

However on the APK, reducing the noise from these unnecessary refreshes has shone a light on something else that is consuming CPU, however not enough CPU to cause the significant slow downs we have seen. This may be due to the fact there is 10,000 cases on the APK install I have and something else is going on. More work to be done there but a different bug I'm assuming.

[rjcorwin]

Oops, it's not the "optimal DOM nodes" level. The recommendation states 1,500 is optimal, we're at 6,200. But at least much better than the 132,000 captured in one of the gifs above.

[rjcorwin]

Fix confirmed by Sante Mali.

[rjcorwin]

Stashing some docs on finding DOM node leaks. I didn't end up finding them useful as I think they are outdated but worth keeping around in case we can find updated docs in the future.

• https://developer.chrome.com/devtools/docs/heap-profiling-dom-leaks
• https://stackoverflow.com/questions/23057287/document-dom-tree-vs-detached-dom-tree