Repository: electron
Issue: [Bug]: Using ThreadSafeFunction in child window causes assertion violation
Labels: platform/windows,bug :beetle:,component/node-integration,status/confirmed,has-repro-repo,25-x-y,26-x-y

### Preflight Checklist

- [X] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/main/CONTRIBUTING.md) for this project.
- [X] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/main/CODE_OF_CONDUCT.md) that this project adheres to.
- [X] I have searched the [issue tracker](https://www.github.com/electron/electron/issues) for a bug report that matches the one I want to file, without success.

### Electron Version

18.0.0

### What operating system are you using?

Windows

### Operating System Version

Windows 10 Pro 19044.1645

### What arch are you using?

x64

### Last Known Working Electron version

16.2.3

### Expected Behavior

Assuming the N-API module is correctly implemented in context-aware matter the render process does not crash.

### Actual Behavior

Crash log observed in the console:

```
C:\Windows\system32\cmd.exe [39088]: ../../third_party/electron_node/src/api/callback.cc:68: Assertion `(Environment::GetCurrent(isolate)) == (env)' failed.
 1: 00007FF7DD474AA6 node::Buffer::New+50438
 2: 00007FF7DD4747E9 node::Buffer::New+49737
 3: 00007FF7DD416A01 node::CallbackScope::CallbackScope+593
 4: 00007FF7DD4167ED node::CallbackScope::CallbackScope+61
 5: 00007FF7DE02CDB9 node::AsyncResource::CallbackScope::CallbackScope+89
 6: 00007FF7DD9D5DDC node_api_get_module_file_name+4092
 7: 00007FF7DD48802C uv_run+492
 8: 00007FF7DBB8DFB8 node::FreeArrayBufferAllocator+23608
 9: 00007FF7DEFA11E8 cppgc::internal::WriteBarrier::DijkstraMarkingBarrierRangeSlow+3187976
10: 00007FF7DF06A492 Cr_z_crc32+629122
11: 00007FF7DD4A30E2 uv_sleep+93074
12: 00007FF7DD4ACBEA uv_sleep+132762
13: 00007FF7DCEE2C45 uv_timer_get_repeat+6778117
14: 00007FF7DD34F202 IsSandboxedProcess+3875010
15: 00007FF7DBC87ECC v8::metrics::LongTaskStats::LongTaskStats+496028
16: 00007FF7DBC889AD v8::metrics::LongTaskStats::LongTaskStats+498813
17: 00007FF7DBC84F3C v8::metrics::LongTaskStats::LongTaskStats+483852
18: 00007FF7DBC852B0 v8::metrics::LongTaskStats::LongTaskStats+484736
19: 00007FF7DBA27F1D std::__1::__vector_base<v8::CpuProfileDeoptFrame,std::__1::allocator<v8::CpuProfileDeoptFrame>>::__vector_base<v8::CpuProfileDeoptFrame,std::__1::allocator<v8::CpuProfileDeoptFrame> >+46541
20: 00007FF7DF3BD8A2 Cr_z_crc32+4115858
21: 00007FF96F727034 BaseThreadInitThunk+20
22: 00007FF96F8C2651 RtlUserThreadStart+33
```

### Testcase Gist URL

_No response_

### Additional Information

I have created a separate reproduction repo with N-API module and a small electron application:
[https://github.com/martinzak-zaber/electron-crash-repro](https://github.com/martinzak-zaber/electron-crash-repro)

### Preconditions ###
```
  webPreferences: {
    nodeIntegration: true,
    contextIsolation: false,
  },
```

### Basic Repro ###

The crash can only be observed in a child window that is opened using `window.open` function on the same domain and loads the same native module. The app crashes after a native module calls `BlockingCall` on `ThreadSafeFunction` created using child's `Napi::Env`. From all my understanding the native module is context-aware and works properly with `Napi::Env`. Sync calls do not seem to be affected.

### Workaround ###

We have come up with two workarounds. The first is to set `nativeWindowOpen` to `false`. This is only possible on `electron < 18`. The second is to return `deny` in `setWindowOpenHandler` and still open the window manually using the provided URL. This works universally.

### Notes ###

The crash does not occur if all the native work is done in preload script (as is perhaps for a lot of applications). The preload script is run only once in that scenario.

I am not 100% confident that this is a bug. I don't have a deep understanding of how v8 isolate and node_env should work in parent-child windows. Perhaps the native module is not correctly implemented.

You may wonder why we use `nodeIntegration` and `contextIsolation`.
It's because our application is strictly desktop and only loads local assets. Using our native node.js library directly makes our development rather convenient.

Thank you, the electron team, and all the contributors for maintaining the amazing ecosystem.