Electron Releases

Description of Change

Keep the WebContentsView visibilityState specs' windows on top on Windows, and run the block serially.

These specs wait for their page to become 'visible'.
A BrowserWindow's own webContents is force-shown, but a BaseWindow's content views aren't, so Chromium's native occlusion tracker decides their visibility.
On the Windows CI hosts, another process's console window can sit above a newly shown test window, and under the parallel runner another worker's window can cover it.
Either way the page stays 'hidden' and waitUntil() times out.
Downstream CI on 42-x-y, 43-x-y and 44-x-y hits this in "tracks visibility for multiple child WebContentsViews", "tracks visibility independently when a child WebContentsView is hidden via setVisible" and "fires a single visibilitychange event per show/hide transition": waitUntil timed out after 10000ms, 30 failures each.

As #54334 did for visibility-state.spec.ts, this creates the block's BaseWindows always-on-top on Windows and tags the block serial.
Other platforms keep a normal window level.
Only test code changes.

Validation

Ran on a local Linux testing build of main under Xvfb:

• e test --files spec/api-web-contents-view.spec.ts -g visibilityState: 9 passed in the serial phase, and 3 of 3 runs passed.
• The Windows-only alwaysOnTop part isn't exercised on Linux.
• script/lint.js --js and tsc -p tsconfig.spec.json pass.

🤖 Generated with Claude Code

Checklist

• I have built and tested this change
• I have filled out the PR description
• I have reviewed and verified the changes
• npm test passes
• tests are changed or added
• PR release notes describe the change in a way relevant to app developers, and are capitalized, punctuated, and past tense.

Release Notes

Notes: none