Description

This PR fixes the flaky test Request Queuing for Multiple Dapps and Txs on different networks. should switch to the dapps network automatically when handling sendTransaction calls .

The problem is that sometimes when we call the const currentWindowHandles = await driver.getAllWindowHandles there is still the previous popup open, meaning that we get the total count of 4 windows.

Right after that, we trigger a send await driver.clickElement('#sendButton'); and now we wait for the windowHandles to be currentWindowHandles + 1 meaning we wait until we have 5 windows. However this will never happen as we should wait for 4 windows instead, but the previous windowCount was considering the previous popup, resulting in 1 more window in total.

  const currentWindowHandles = await driver.getAllWindowHandles();
  await driver.clickElement('#sendButton');
  const newWindowHandles = await driver.waitUntilXWindowHandles(
    process.env.ENABLE_MV3
      ? currentWindowHandles.length
      : currentWindowHandles.length + 1,

The proposed fix is to hardcode the expect number of windows directly, as we know how many there should be and we do this in the majority of the tests. There could be alternative approaches,

• wait for a condition: though in this case the condition of having switched networks is already met in the wallet, so there doesn't seem to be another condition to wait for 🤔
• add a delay

Related issues

Fixes: the third item of this list #24603

Manual testing steps

1. Run the test several times yarn test:e2e:single test/e2e/tests/request-queuing/ui.spec.js --browser=chrome --leave-running --retryUntilFailure --retries=10
2. Check ci jobs

Screenshots/Recordings

See how at one point, we get current windows as 4 (we expected 3) because the popup was still not closed and the next time we trigger a tx, we would expect 4+1, which will never happen.

Pre-merge author checklist

• I’ve followed MetaMask Coding Standards.
• I've completed the PR template to the best of my ability
• 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.

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.