fix: flaky test Queued Confirmations Queued Requests Banner Alert Banner is shown on dApp 1, but not on dApp 2 after adding transaction on dApp 1, and one on dApp 2 (old confirmation flow)

[seaona]

Description

The test Queued Confirmations Queued Requests Banner Alert Banner is shown on dApp 1, but not on dApp 2 after adding transaction on dApp 1, and one on dApp 2 (old confirmation flow) is flaky and fails with the following error.:

There is one fundamental problem which is that in the test we expect that switchChain will trigger a dialog, but that shouldn't be the case, as we already have permissions to that network (comes selected by default, see video below). Then the window management is messed up.

Roughly:

• Whenever we connect to the dapp2, we don't wait for the dialog window to close
• We switch to dapp 1
• We trigger a switchChain request --> here we wait for the dialog to be there. The problem is that the switchChain request don't trigger a dialog (that's expected as that network already has permissions by default)
• So now, depending on how fast the dialog from step 1 remains open, will make it to the next step, or not (if the dialog is close fast enough). That's why it doesn't fail all the time (but it should, given the incorrect expectation of waiting for a dialog after the request to switch chains, to an already approved chain)
• Then the subsequent actions can work with an old instance of the dialog, but that is closed after some seconds (as it was the Connect dialog which we already accepted) making it fail

Related issues

Fixes: #30012

Manual testing steps

1. Check ci run Note: you'll see there's a spec failing but that's a different one that will be tackled in a separate PR, issue here
2. Run test locally yarn test:e2e:single test/e2e/tests/confirmations/alerts/queued-confirmations.spec.ts --browser=chrome --leave-running=true

Screenshots/Recordings

See how the localhost 7777 is already selected by default. This willl make that any request to switch to that chain won't trigger any dialog (ExpecteD)

connect-permissions-default.mp4

See same behaviour in a prod build

prod-connect-default.mp4

Pre-merge author checklist

• I've followed MetaMask Contributor Docs and MetaMask Extension 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.

[github-actions]

CLA Signature Action: All authors have signed the CLA. You may need to manually re-run the blocking PR check if it doesn't pass in a few minutes.

[seaona]

race condition here, we need to wait for the dialog to close, before proceeding to the dapp 1 window

[seaona]

incorrect expectations, as the dialog should never open in this case, as that network already has permissions. We should just expect that the network has been switched.
The incorrect expectations together with the above race condition, made that this test passes sometimes, because we wait for 4 windows, and this is the case if the dialog from the step before is not closed fast enough (is possible because we didn't wait for the dialog to close in the first place), but that dialog instance doesn't exist anymore in the next steps

[seaona]

we just wait for the test dapp to have switched to the new network

[metamaskbot]

Builds ready [3221328]

• builds: chrome, firefox
• builds (flask): chrome, firefox
• builds (MMI): chrome
• builds (test): chrome, firefox
• builds (test-flask): chrome, firefox
• build viz: Build System
• mv3: Bundle Size Stats
• mv2: E2e Actions Stats
• storybook: Storybook
• typescript migration: Dashboard
• all artifacts
• bundle viz:

  • background: 0, 1, 2, 3, 4, 5, 6, 7
  • common: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13
  • ui: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13
  • content-script: 0
  • offscreen: 0

Page Load Metrics (1772 ± 79 ms)

Platform	Page	Metric	Min (ms)	Max (ms)	Average (ms)	StandardDeviation (ms)	MarginOfError (ms)
Chrome	Home	firstPaint	1582	2207	1777	163	78
		domContentLoaded	1560	2128	1743	151	73
		load	1586	2209	1772	165	79
		domInteractive	25	99	46	24	11
		backgroundConnect	8	80	34	25	12
		firstReactRender	16	73	37	22	11
		getState	4	48	12	10	5
		initialActions	0	0	0	0	0
		loadScripts	1070	1620	1279	132	63
		setupStore	7	67	24	20	10
		uiStartup	1737	2473	2014	183	88

Bundle size diffs

• background: 0 Bytes (0.00%)
• ui: 0 Bytes (0.00%)
• common: 0 Bytes (0.00%)