Description

We've been having a lot of issues recently with flaky tests where the error is something like

ElementClickInterceptedError: Element <div class="mm-box multichain-app-header-logo mm-box--margin-2 mm-box--display-none mm-box--sm:display-flex mm-box--justify-content-center mm-box--align-items-center"> is not clickable at point (576,45) because another element <div class="mm-box loading-overlay"> obscures it

We have been fixing these flaky tests one at a time, but I realized that there's a more general solution.

Every time you try to click on an element, catch an ElementClickInterceptedError, wait for .loading-overlay to disappear, and try again!

Related issues

Manual testing steps

Yes, this is kind of hard to test, because you're looking for the lack of a certain type of flakiness. But I came up with the following test procedure:

1. In driver.js, comment out the whole block from lines 72-95. This effectively reverts this PR.
2. In routes.component.js, on line 130, add const startTime = performance.now();
3. In routes.component.js, around what is now line 621, replace the whole isLoadingShown expression with
   let isLoadingShown = performance.now() - startTime < 8000;
4. The loading overlay should now be on for 8 seconds, causing most E2E tests to fail
5. Uncomment lines 72-95 from driver.js
6. The new click() method is active, and E2E tests pass even though the loading overlay is in front for 8 seconds

Screenshots/Recordings

Pre-merge author checklist

• I’ve followed MetaMask Coding Standards.
• I've clearly explained what problem this PR is solving and how it is solved.
• I've linked related issues
• I've included manual testing steps
• I've included screenshots/recordings if applicable
• I’ve included tests if applicable
• I’ve documented my code using JSDoc format if applicable
• I’ve applied the right labels on the PR (see labeling guidelines). Not required for external contributors.
• I’ve properly set the pull request status:
  • In case it's not yet "ready for review", I've set it to "draft".
  • In case it's "ready for review", I've changed it from "draft" to "non-draft".

Pre-merge reviewer checklist

• I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed).
• I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots.