LG-14753 Bug fix for sign-in page losing user progress

[kevinsmaster5]

🎫 Ticket

Link to the relevant ticket:
LG-14753

🛠 Summary of changes

Adds a modal to sign in page to keep user progress. Utilizes similar feature as for a logged-in user that informs them their session is about to expire and be logged out.

📜 Testing Plan

(to make testing quicker set session_timeout_in_minutes: 5 in local application.yml)

• Go to http://localhost:3000
• Enter email, password but do not click sign-in
• Wait for timeout to get close to elapsing
• Observe that a modal timeout warning countdown appears
• Click Continue Sign In
• Note form values remain
• Click Cancel Sign In
• Note the page reloads and form is cleared

[aduth]

If I'm following this correctly, this test will take 10 real-world seconds to complete, so the three tests here will add 30 seconds delay to every CI build. It also implicitly relies on the default session timeout warning config value being 150 seconds, so the test might break if we changed that default.

I'd suggest:

• Minimizing the time it takes for the test to run. Could this be 151 seconds instead of 160, for example?
• Avoiding implicit dependency on the default config value by either calculating the value using the actual config (IdentityConfig.store.session_timeout_warning_seconds + 1), or by stubbing the config value to gaurantee that it's the 150 we're expecting (expect(IdentityConfig.store).to receive(:session_timeout_warning_seconds).and_return(150))

[kevinsmaster5]

Agree the timing was creating some challenges getting the fields populated before the modal showed up. 151 seems to work OK but am I still dragging the duration with wait: 10?

[aduth]

The wait should be okay, since it'll wait up to 10 seconds, but won't hold up the rest of the test if it finds what it's expecting sooner than that.

[aduth]

Can you also make the change from the second bullet point in #11783 (comment) ? We're still hard-coding the value implicitly depending on the current configuration default.

[kevinsmaster5]

I think I got that now.

[aduth]

LGTM! 👍

[aduth]

I think this change makes sense considering what the spec is testing, but I'm surprised why it's suddenly necessary?

[kevinsmaster5]

I think it was a similar timing problem that got created by adding the modal to the sign-in page.
Specifically you get an element not interactable error

 Selenium::WebDriver::Error::ElementNotInteractableError:
       element not interactable
         (Session info: chrome=132.0.6834.160)

I figured that was because the modal is in the way and it can't fill in the form in the helper.

[aduth]

Hm I wonder if that was just a flakey test failure. I've seen those before with these modals. Looking at what sign_in_before_2fa and sign_in_user are doing, I can't really imagine it should make much of a difference.

[kevinsmaster5]

It looks like by adding the session timeout it no longer has that error.