Regardless of the `browserWindowOptions.show` value, a window always opens. about karma-electron HOT 12 CLOSED

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)

from karma-electron.

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

from karma-electron.

So far:

• I've upgraded to [email protected] 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)

from karma-electron.

• 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)

from karma-electron.

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)

from karma-electron.

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

from karma-electron.

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

from karma-electron.

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

from karma-electron.

Resuming the journey on this

from karma-electron.

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

from karma-electron.

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

from karma-electron.

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

from karma-electron.