Attempt to reduce noise with isUnsupportedBrowser

[caleybrock]

Our only guess right now is that this could be a timing thing, since it only happens sometimes.
We can definitely reduce noise by checking if it's on window first, but this represents a real error with how we include common js in pegasus so I don't want to totally silence it. @Bjvanminnen's idea was to add a timeout before making the check to see if it eventually gets added to window.

[Bjvanminnen]

So if this is successful in reducing our error rate, that means we almost certainly have a timing issue that we don't fully understand or think we should have. At that point, I don't know that we should consider this issue fixed.

If this does not reduce our error rate, I believe it implies our misunderstanding is either somewhere else, or we have a timing issue where the window is > 5s.

[caleybrock]

I'll also note here that I tested user impact. The only case where this impacts the user, is if they are on an unsupported browser, and have this timing issue, they won't see a banner telling them that their browser is unsupported. If they get the error on a supported browser, there is no impact.

[islemaster]

This is fine, but why haven't we just moved this $(document).ready code out of the haml files and into whatever bundle is providing isUnsupportedBrowser in the first place? It's not clear to me that it ever needs to be on window at all.

[islemaster]

This is a really small nit, but I would have written:

setTimeout(() => {
  if (isUnsupportedBrowser()) {
    $('#warning-banner').show();
  }
}, window.isUnsupportedBrowser ? 0 : 5000);

...which doesn't have quite the same meaning (because it introduces a setTimeout(_, 0)) but in this case might be good enough, and might be easier to reason about (e.g. we will always run this callback, it's just a question of when).

[Bjvanminnen]

One downside to that approach Brad is that in the case where isUnsupportedBrowser is undefined, we won't be able to tell from the callstack in NR whether it's on the initial load or on the delayed load.

[Bjvanminnen]

I don't envision the current approach as a long term solution, but rather a short term solution that (a) reduces noise and (b) provides us with some additional information about what's failing (i.e. is it actually a timing issue or something else) that will hopefully make it easier for us to find a long term solution.

[islemaster]

That is a good point about different callstacks.

[davidsbailey]

LGTM as a way to gather more data. The timing issue seems like it would be hard to debug, so I like that this will help us determine if timing is really part of the problem.