Regardless of the `browserWindowOptions.show` value, a window always opens.

[trusktr]

I thought that browserWindowOptions.show being set to false would hide the window. However regardless of the value, windows always appear during testing.

It's not a big deal though: on CI I use xvfb-maybe to make it "headless" regardless, but I was curious as to what the actual result of browserWindowOptions.show should be.

[twolfson]

I've confirmed that this is a bug by running:

npm run test-karma-continuous -- --browsers VisibleElectron

and toggling show: true/false in the karma.conf.js

Though, it's strange because there's 1 less window when we do true/false, so it makes me think something is working -- just unsure what has changed ._.

I'm pretty busy so I can't guarantee an immediate turnaround time, maybe by the end of next week? (probably will be a lot sooner, I don't like known bugs sticking around too long)

[twolfson]

Trying to tackle this, though kind of tired. We'll see how far I get

[twolfson]

So far:

• I've upgraded to electron@12.1.2 to verify that's not the issue
• Still seeing windows show up
• When I change the target URL from Karma's location to https://google.com/, the browser window no longer shows up
  • So it's probably something Karma is doing (e.g. window.open or similar)

[twolfson]

• Throwing an error to find out what page Karma is launching to (because console.log from the Electron launcher doesn't pass through =/
• Verifying we're loading karma/static/client.html
• Commenting out lines in that code to see what causes/stops causing the issue (looks like karma.js)

[twolfson]

Yep, this is window.open misbehaving in Electron:

• Iterated on karma/static/karma.js, saw it receive window.open as opener, disabled their opener(url), and swapped in an identifiable one (i.e. opener('https://google.com/'))
• Verified child window is visible both when show: true and show: false (despite parent window not being)

[twolfson]

Behavior still persists on electron@15. Seems like this is a bug in Electron so will see if there's anything existing to watch

[twolfson]

Ah, it seems there's a windowOpenHandler we can configure so going to do that

https://github.com/electron/electron/blob/v12.1.2/docs/api/window-open.md#windowopenurl-framename-features

https://github.com/electron/electron/blob/v12.1.2/docs/api/web-contents.md#contentssetwindowopenhandlerhandler

[twolfson]

Well that did remedy the issue, but now the tests are failing so it might have overdone it -- and I'm noticing a nativeWindowOpen a few lines up that I'd like to understand. But I'm out of energy for tonight =/ Will resume another day

https://github.com/twolfson/karma-electron/blob/bc60482ba3d835099fa97d72ff3f3e1c9890266b/lib/electron-launcher.js#L95-L102

[twolfson]

Resuming the journey on this

[twolfson]

So it looks like the only piece of the tests that are failing right now is a Node.js parity one (i.e. module.parent is undefined as expected but that's not an actually defined attribute (i.e. no hasOwnProperty), which is inconsistent =/

That being said, the nativeWindowOpen: true a few lines up that I'd noticed was introduced in 7.0.0 as part of supporting electron@12 so that's prob fine

[twolfson]

Ah, the module.parent property was moved to module.__proto__. But that also seems to just be an electron@12 -> electron@15 change so we're fine =P

I think the patch setWindowOpenHandler will work fine. Going to create a clean branch, test it, and :shipit:

[twolfson]

This has been patched with setWindowOpenHandler, tested, and released in 7.1.0. Thanks again for the bug report! =D