Failed IPC communication with playwright smoke tests from preload script

[rebornix]

1) VSCode Smoke Tests (Electron)
       Quick Open
         "before all" hook for "quick open search produces correct result":
     locator.waitFor: Timeout 40000ms exceeded.
=========================== logs ===========================
waiting for selector ".monaco-workbench" to be visible
============================================================
      at Application.checkWindowReady (D:\a\_work\1\s\test\automation\src\application.ts:149:56)
      at Application._start (D:\a\_work\1\s\test\automation\src\application.ts:98:4)
      at Application.start (D:\a\_work\1\s\test\automation\src\application.ts:75:3)
      at Context.<anonymous> (src\utils.ts:92:3)

https://dev.azure.com/monacotools/Monaco/_build/results?buildId=165034&view=logs&j=672276a2-8d3a-5fab-615d-090c51352f92&t=9302e8c4-de85-5274-34fa-935ce79d4e8d

[bpasero]

Yes this is from the new smoke tests with playwright, they are marked to not fail the build though.

[bpasero]

This is our master issue for tracking the Windows issues for using playwright.

/cc @pavelfeldman

[bpasero]

More logging reveals that the window awaits a IPC reply from the main process to continue loading the workbench but the response is never reaching the window.

Here is the flow:

• electron main process opens a ipcMain.handle (from here before the window loadUrl is called)
• window loads preload.js first which will immediately call on the ipcRenderer.invoke (from here)
• we await the config object to be resolved

Unclear to me what could trigger this in Electron, maybe it is related to the extra inspect/debugging related properties playwright passes on:

D:\a\_work\1\VSCode-win32-x64\Code - Insiders.exe --inspect=0 --remote-debugging-port=0 C:\Users\CLOUDT~1\AppData\Local\Temp\vscsmoke\vscode-smoketest-express --skip-release-notes --skip-welcome --disable-telemetry --no-cached-data --disable-updates --disable-keytar --disable-crash-reporter --disable-workspace-trust --extensions-dir=C:\Users\CLOUDT~1\AppData\Local\Temp\vscsmoke\extensions-dir --user-data-dir=C:\Users\CLOUDT~1\AppData\Local\Temp\vscsmoke\d-zfp3rzpv --logsPath=D:\a\_work\1\s\.build\logs\smoke-tests-electron --enable-proposed-api=vscode.vscode-notebook-tests --enable-smoke-test-driver true

[bpasero]

Mitigated by doing a window reload after timeout of 10 seconds. This change only impacts smoke tests, I am hesitant to change something in our preload or bootstrap files until real users report this.

Still would be interesting to figure out if this is a Electron regression.

[bpasero]

@deepak1556 while I can mitigate the hang in the renderer by doing a window reload, I cannot mitigate it for the shared process where this is also happening and is most likely the cause of #146800

Would it be possible to do an internal build where electron/electron#33323 is reverted to see if that is the cause?

[deepak1556]

@bpasero turns out the above change and electron/electron@3001b69 was reverted internally by Teams since it caused a regression on their end for their custom ipc implementations and never made it into our product builds. This could also explain why it was only seen with CI. The changes have now been added back in and I am currently creating newer builds. Pretty sure this is very likely related to the root issue sharing the cause sender.url being an empty string when using playwright for testing in #147301. Playwright is causing some sort of frame swap on initial load causing the empty url as well as https://github.com/electron/electron/blob/31c2b5703a75a5ff2bf0e68f472d9002fe866bfb/shell/browser/electron_browser_client.cc#L1558-L1559 condition to fail. I will look into this further once we have newer builds.

[bpasero]

Thanks ❤️ , I forgot that we use different builds in our CI for smoke tests, so that is a good thing to keep in mind going forward.

Curious what kind of issue Teams folks saw with IPC, maybe we can connect the dots with our issue.

[bpasero]

Optimistically closing, will reopen when this happens again, I have removed all our workarounds.