-
-
Notifications
You must be signed in to change notification settings - Fork 2.7k
Open
Labels
Description
Have you read the Contributing Guidelines on issues?
- I have read the Contributing Guidelines on issues.
WebdriverIO Version
9.23.2
Node.js Version
24.11.1
Mode
Standalone Mode
Which capabilities are you using?
export const config: WebdriverIO.MultiremoteConfig = {
//
// ====================
// Runner Configuration
// ====================
//
runner: 'local',
//
// ==================
// Specify Test Files
// ==================
//
specs: [
'./test/specs/**/*.e2e.test.ts'
],
//
// ============
// Capabilities
// ============
//
maxInstances: 10,
capabilities: {
myChromeBrowser: {
capabilities: {
browserName: 'chrome',
'goog:chromeOptions': {
// args: ['--headless', '--disable-gpu']
}
}
},
myFirefoxBrowser: {
capabilities: {
browserName: 'firefox',
'moz:firefoxOptions': {
// args: ['-headless']
}
}
}
},
//
// ===================
// Test Configurations
// ===================
//
logLevel: 'info',
bail: 0,
baseUrl: 'http://localhost',
waitforTimeout: 10000,
connectionRetryTimeout: 120000,
connectionRetryCount: 3,
services: [],
framework: 'mocha',
reporters: ['spec'],
mochaOpts: {
ui: 'bdd',
timeout: 60000
},
//
// =====
// Hooks
// =====
//
before: function (capabilities, specs) {
// require('expect-webdriverio') // Not needed if using types in tsconfig and auto-import, but good to be safe or if using JS.
// Actually, with the latest expect-webdriverio, it is often auto-imported or we import it in the test.
// But let's verify how to properly setup expect-webdriverio.
},
}What happened?
When opening two browsers in multi-remote and closing one of them, the session is killed with the following error
All window handles were removed, causing WebdriverIO to close the session.
However, there is still one window open, and the session should not be closed.
The doc is clear that it should close IF there is no more browers but there is still one
The Close Window command closes the current top-level browsing context. Once done, if there are no more top-level browsing contexts open, the WebDriver session itself is closed.
What is your expected behavior?
Close the session only when all of the windows are closed.
How to reproduce the bug.
With multi-remote config, run the test and you can see that 1 window stays open, but the test failing
describe('closeWindow', () => {
it.only('should close top-level and continue without failing', async () => {
await multiRemoteBrowser.url('https://the-internet.herokuapp.com/login')
await expect(multiRemoteBrowser.myFirefoxBrowser).toHaveTitle('The Internet')
await expect(multiRemoteBrowser.myChromeBrowser).toHaveTitle('The Internet')
const handles = await multiRemoteBrowser.myChromeBrowser.closeWindow()
console.log('Handles after closeWindow:', handles);
await expect(multiRemoteBrowser.myFirefoxBrowser).toHaveTitle('The Internet')
})
}) type.d.ts
declare namespace WebdriverIO {
interface MultiRemoteBrowser {
myChromeBrowser: WebdriverIO.Browser
myFirefoxBrowser: WebdriverIO.Browser
}
}
Relevant log output
MultiremoteBrowser on chrome and firefox #0-0] 1) closeWindow should close top-level and continue without failing
[MultiremoteBrowser on chrome and firefox #0-0] All window handles were removed, causing WebdriverIO to close the session.
[MultiremoteBrowser on chrome and firefox #0-0] Error: All window handles were removed, causing WebdriverIO to close the session.
[MultiremoteBrowser on chrome and firefox #0-0] at <anonymous> (/Users/Git/expect-webdriverio-boilerplate/node_modules/mitt/src/index.ts:109:7)
[MultiremoteBrowser on chrome and firefox #0-0] at Array.map (<anonymous>)
[MultiremoteBrowser on chrome and firefox #0-0] at Object.emit (/Users/Git/expect-webdriverio-boilerplate/node_modules/mitt/src/index.ts:108:7)
[MultiremoteBrowser on chrome and firefox #0-0] at async Context.<anonymous> (/Users/Git/expect-webdriverio-boilerplate/test/specs/example.e2e.test.ts:168:29)Code of Conduct
- I agree to follow this project's Code of Conduct
Is there an existing issue for this?
- I have searched the existing issues
Reactions are currently unavailable