10349 Bug: Idle Logout Issues (with automated tests)

[Mwindo]

See ticket for bug details.

There ended up being several issues related to idle sign-out behavior. Broadly, they were the following:

• With multiple tabs open, idle logout behavior was not always consistent.
• Message alerts (e.g., "Success" or "Failure" boxes) remained on the sign in screen after being logged out.
• The app could attempt to sign out an idle user when the client needed to refresh, which would cause confusing front-end behavior (e.g., infinite loading icon).

This PR enforces the following behavior:

1. New tabs start tracking the idle behavior of the user on page load rather than on interaction, which ensures tabs' idle timeouts are synced.
2. New tabs dismiss "Are you still there?" modals in other (possibly older, forgotten) tabs to prevent potential surprise logouts in the current tab.
3. Multiple tabs signing out at the same time all end up at the Idle Logout screen. (Before this PR, some tabs ended up at the Idle Logout screen, some ended up at the Login screen, and some ended up with an infinite-until-refresh loading icon).
4. We broadcast the "you need to close and refresh" event to all tabs to keep them consistent.
5. We do not track idle behavior or sign the user out if the client needs to be refreshed.
6. We reset the idle time tracking when the user signs out to prevent the "Are you still there?" modal from appearing in some cases immediately upon signing in.

[Mwindo]

EDIT: After discussion, having the automated tests seemed better than not having them. If they ever become flaky or problematic to maintain, we can ditch them.

Original comment below

---

@jimlerza @zacharyrogers1 Could you take a look at the new testing paradigm here (don't worry about the other stuff for now) and see what you think? I'm happy to get rid of it all if you guys don't think it is worthwhile, but "it's working on my machine."

The basic idea:

1. Expose the cerebral controller on the window object in non-production environments (see app.tsx).
2. With that exposed, we can override any constants in our cypress tests--in my case, the idle timeouts. See idleLogoutHelpers.ts.
3. Native cypress cannot open multiple tabs, and no tests I did to "fake" multiple tabs were effective. I therefore used the cypress puppeteer plugin, which is apparently in public beta but is listed on the "official" plugins page. This configuration is mostly in cypress.config.ts, with the tests in idle-logout.cy.ts.

As far as I can tell, the pros:

• We can test things involving multiple tabs.
• We have specific tests for cross-tab logout behavior. (One or two tests TBD, if I continue down this route.)
• The tests aren't beautiful, but they aren't terrible.

The cons:

• The puppeteer plugin is a new dependency.
• Exposing the cerebral controller isn't my favorite thing in the world.
• The tests represent a small degree of new complexity to manage.
• If we decide this is a reasonable approach, I will have to determine why the checks are failing in GA despite succeeding consistently locally. EDIT: They are working. Funnily enough, this was the most challenging portion of the PR.

[Mwindo]

Although we clear the idle activity interval in IdleActivityMonitor, there is still be a brief period in which this could be called before the interval has been cleared.

[Mwindo]

Originally, the "user is logged in?" check was short-circuiting, just like I have it here. Looking at the Git history, the check was accidentally moved into the first if block. After moving it back out, I also refactored the if/else if into multiple independent if blocks for easier readability since this was an easy mistake to make.

[jimlerza]

Nice catch!