Error invoking remote method 'wdio-electron.execute': ReferenceError: __name is not defined after update to wdio 9 and wdio-electron-service 7

[RedX2501]

I'm using wdio 9.0.7 and wdio-electron-service 7.0.1.

With 8.40.3 and 6.6.1 I never received this error.

Now tests that use a function defined in a browser.electron.execute block fail with the message:

[0-0] javascript error in "Electron Testing.Sanity Tests.can click on menu"
javascript error: javascript error: Error invoking remote method 'wdio-electron.execute': ReferenceError: __name is not defined
  (Session info: chrome=122.0.6261.129)
    at ElectronWorkerService.execute (C:\data\_eev\eev_test\node_modules\wdio-electron-service\src\commands\execute.ts:21:23)
    at clickMenuItem (c:\data\_eev\eev_test\test\specs\test.e2e.ts:139:3)
    at Context.<anonymous> (c:\data\_eev\eev_test\test\specs\test.e2e.ts:467:7)

I have simplified the function to the following:

async function clickMenuItem(...names: string[]): Promise<void> {
  await browser.electron.execute(async (electron, menuNameArr) => {
    function nested(an_arg:any): any{
      return null;
    }
    nested("any arg");
  }, names);
}

replacing this with

async function clickMenuItem(...names: string[]): Promise<void> {
  await browser.electron.execute(async (electron, menuNameArr) => {
    console.log("checkpoint");
  }, names);
}

and the error is gone.

package.json:

{
  "name": "eev_test",
  "type": "module",
  "devDependencies": {
    "@testing-library/jest-dom": "^6.1.3",
    "@testing-library/react": "^14.0.0",
    "@testing-library/user-event": "^14.5.2",
    "@testing-library/webdriverio": "^3.2.1",
    "@wdio/cli": "^9.0.0",
    "@wdio/local-runner": "^9.0.0",
    "@wdio/mocha-framework": "^9.0.0",
    "@wdio/spec-reporter": "^9.0.0",
    "@wdio/visual-service": "^5.2.1",
    "electron": "^29.1.4",
    "ts-node": "^10.9.2",
    "typescript": "^5.5.4",
    "wdio-electron-service": "^7.0.0",
    "wdio-html-nice-reporter": "^8.1.6"
  },
  "scripts": {
    "wdio": "wdio run ./wdio.conf.ts"
  }
}

Any workarounds for this? It seems that due to the context I cannot declare the helper function outside of the execute block.

[goosewobbler]

It could be that passing the function to the main process over the IPC boundary it loses some property of the nested function. Did you make this broken simplified function after you updated WDIO or was the code for this test exactly the same in both versions?

What happens if you replace the function with const nested = () => null?

[RedX2501]

The simplified function was only used in v7.
I used the simplified code i provided in my test to make sure it's really breaking and it is. Removing the nested function makes v7 accept the snippet i provided.

The original code works in v6 and breaks in v7. I didn't see the point in posting it here since even this small piece of code already displays the same problem.

I'll try tomorrow what happens when i try sort suggestion.

[christian-bromann]

This is a known issue within WebdriverIO (webdriverio/webdriverio#13444) which I am currently working on resolving. ETA for a release is either today or tomorrow.

[goosewobbler]

Closed as duplicate of the WDIO issue.

[gavvvr]

Hi @goosewobbler

I think this one should be reopened.
Even after webdriverio/webdriverio#13444 was fixed, this is still reproducible in Elecrton e2e test.

Here is how to reproduce:

1. Create a new electron app: npm init electron-app@latest wdio-electron-hello-world && cd wdio-electron-hello-world
2. Init sample WDIO setup for testing Electron app: npm init wdio@latest .
3. add the following piece of code to generated test:

await browser.execute(() => {
    const uploadStub = () => 'boom!'
})

4. Build the app and run e2e test: npm run package, npm run wdio

Here is the error:

[0-0] 2024-09-06T19:53:12.048Z INFO webdriver: [POST] http://localhost:52749/session/cf9318e5dc4474f1e9b023c0942982a5/execute/sync
[0-0] 2024-09-06T19:53:12.048Z INFO webdriver: DATA {
[0-0]   script: 'return (()=>{const uploadStub=__name(()=>"boom!","uploadStub")}).apply(null, arguments)',
[0-0]   args: []
[0-0] }
[0-0] 2024-09-06T19:53:12.051Z ERROR webdriver: Request failed with status 500 due to javascript error: javascript error: __name is not defined
[0-0]   (Session info: chrome=128.0.6613.84)
[0-0] javascript error in "Electron Testing.should print application title"
javascript error: javascript error: __name is not defined
  (Session info: chrome=128.0.6613.84)
    at async Context.<anonymous> (/Users/user/Documents/sandboxes/wdio-electron-hello-world/test/specs/test.e2e.js:6:9)

[goosewobbler]

We need to find out why the fix in the above WDIO ticket is not working here. Using #763 to work on it.

[gavvvr]

Hi @goosewobbler
I've just tested this simple piece of code:

await browser.execute(() => {
    const uploadStub = () => 'boom!'
})

with 7.0.2 and, unfortunately, it still fails with:

javascript error: javascript error: __name is not defined
  (Session info: chrome=128.0.6613.84)
    at async Context.<anonymous> (/Users/user/Documents/sandboxes/wdio-electron-hello-world-ts/test/specs/test.e2e.ts:6:9)

[goosewobbler]

@gavvvr I forgot to update wdio-electron-service-example with the new E2Es, however I just did so and they fail with 7.0.1 as expected, and pass with 7.0.2 -- as do the E2Es in this repo.

I'm going to need a new example repo showing a failure with 7.0.2...

[goosewobbler]

Closing until I get more evidence that this is still an issue.

[gavvvr]

Hello @goosewobbler
Here is the repo reproducing the __name is not defined probem:
https://github.com/gavvvr/wdio-electron-service-756

[goosewobbler]

Here is the repo reproducing the __name is not defined probem: gavvvr/wdio-electron-service-756

@gavvvr The issue here seems to be that the displayed error is masking the true error, which is that the execute function is being called without the IPC bridge being enabled. The service currently uses an IPC bridge to provide access to the electron main process, execute shouldn't work without it and in your example repo it should be displaying the error Electron context bridge not available!..., instead of the __name error.

This explains why it works in the E2Es, because they all enable the bridge. I'm not going to create E2Es which run on a bridgeless app, as we are looking to get rid of it and the rapidly shrinking amount of time I can spend on this service is better spent there.

I'll reopen and try to find a more comprehensive fix to improve the error here, otherwise I'll just document it as a known issue.

As far as workarounds you can either:

• Use JS
  • the root cause is an esbuild bug which is exposed via our use of tsx to run TS specs
• Use the IPC bridge as specified in the docs
  • you won't be able to use execute without it anyway!

[goosewobbler]

Ok, closing again. @gavvvr you were using the wrong function. The test should be calling browser.electron.execute but it's calling browser.execute. If you use the correct function then you get the expected error for the IPC bridge being unavailable.

Since browser.electron.execute is just a wrapper for browser.execute, it does mean that the fix should be in the WDIO repo though, rather than here. We'll continue discussion over there in the original bug.

[gavvvr]

@goosewobbler thank you for your analysis of my issue!

The service currently uses an IPC bridge to provide access to the electron main process, ...

Unfortunately, I can't use browser.electron.execute because I don't have any control over the source code of the Electron app I'm testing, hence I can't add imports for enabling IPC bridge. I'm just developing and testing a small plugin for that Electron app.

... execute shouldn't work without it

Use the IPC bridge as specified in the docs

• you won't be able to use execute without it anyway!

From my experience, this is not quite true...

The regular browser.execute function worked for my Electron e2e test for half a year of using wdio-electron-service without IPC bridge. Here is the real test from my project, which is using browser.execute and it still works on the commit I referenced with WDIO v8.40.3 (or the latest v8.x, which is v8.40.5) + wdio-electron-service v7.0.1 (or the latest v7.0.2). For me the issue begins with any WDIO v9.x version, and I initially reported about it main WDIO project.

I reported for the first time here, when Christian Bromann had already closed the original issue and the problem has disappeared for a similar browser's e2e test using WDIO v9.0.9 + TypeScript. I decided that it's a wdio-electron-service-specific problem now, because I was only able to reproduce it in Electron service test using TypeScript, browser's tests are fine with the latest WDIO v9.x now.

[goosewobbler]

• you won't be able to use execute without it anyway!

From my experience, this is not quite true...

I wasn't clear here - you can't use browser.electron.execute without the bridge.

The regular browser.execute function worked for my Electron e2e test for half a year of using wdio-electron-service without IPC bridge. Here is the real test from my project, which is using browser.execute and it still works on the commit I referenced with WDIO v8.40.3 (or the latest v8.x, which is v8.40.5) + wdio-electron-service v7.0.1 (or the latest v7.0.2).

Interesting, presumably you can't access Electron APIs that way?

I decided that it's a wdio-electron-service-specific problem now, because I was only able to reproduce it in Electron service test using TypeScript, browser's tests are fine with the latest WDIO v9.x now.

I'm still not convinced it is a service issue as browser.execute is not altered in any way from the core WDIO object. In any case, using browser.execute to add the workaround to the global object in the before hook does seem to fix the issue for browser.execute. I also updated the E2Es to cover both browser.electron.execute and browser.execute cases, these can all be removed when the tsx / esbuild issue is finally resolved.

I released 7.0.3 but there's some issue with the release process, for some reason the published module is looking for 7.0.2 of its dependencies...

[goosewobbler]

Still some issue with the version of @wdio/electron-types being one behind on release, but this issue is fixed with 7.0.4.