fix(4882): reduce ResizerObserver looping even further

[wiedld]

Part of #4882

Part of bug squashing mission.

Bug:

• general window.onerror triggered via the ResizeObserver
• What this is:
  • Excessive recursion upon resize. But is a know issue because of how this window API should be used, and is chrome-specific behavior (matching what we see in honeybadger for the browsers).
  • This is expected, and highly reported elsewhere:
    • https://stackoverflow.com/questions/49384120/resizeobserver-loop-limit-exceeded
    • https://github.com/WICG/resize-observer/issues/38
• Previously done:
  • we are already doing 2 (out of 3) code patterns to reduce the triggering occurrences. We can also do the 3rd one too (cancel animation frame).

In addition to this PR, going to be requesting permission to start filtering out (ignoring) this error in honeybadger.

[hoorayimhelping]

do you know why this RAF is in a setTimeout?

[wiedld]

There is a general pattern when using ResizeObserver --> to then trigger a callback (e.g. set height of inner component) which then may recursively trigger ResizeObserver again. This is a known problem, which is why browsers do not surface these errors in the console...but it does still gets report in window.onerror() --> which we pipe to honeybadger.

Here is an issue ticket from WICG, which includes this^^ conclusion, as well as many code samples where a community of devs have listed all the code patterns which they use to decrease the number of recursive triggers (although is impossible to eliminate). One of the patterns is to have the callback action be encapsulated in a setTimeout() (https://github.com/WICG/resize-observer/issues/38#issuecomment-422085926), which queues it up at the back of the javascript runtime macrotask queue.

[hoorayimhelping]

One of the patterns is to have the callback action be encapsulated in a setTimeout() which queues it up at the back of the javascript runtime macrotask queue.

Thanks for the explanation. Is the 200 millisecond delay significant? Could this could this be achieved with a delay of 1 or 0 milliseconds? The example doesn't set the delay value explicitly, which defaults it to a value of 0

[wiedld]

The timeout was put in previously. I can only guess the 200ms is arbitrary. The 0 is sufficient for insertion at the back of the macrotask queue.