Question: client window active status in the headless mode?

[OrKoN]

https://w3c.github.io/webdriver-bidi/#get-the-client-window-info says:

If client window can receive keyboard input channeled from the operating system, let active be true, otherwise let active be false.

what does it mean for the headless mode of running the browser when no windows are visible? should all windows be active=false or active=true? should browsers in the headless mode accept keyboard input from the user or only allow input via the protocol?

the headless mode is not really standardized but Firefox and Chrome support it and it might be relevant for the users to get consistent active status across headless browsers.

cc @sadym-chromium

[OrKoN]

A test case:

import puppeteer from "puppeteer";

const browser = await puppeteer.launch({
  browser: 'firefox',
});

const page = await browser.newPage();

await page.goto('https://domeventviewer.com/key-event-viewer.html');

console.log('type now')

console.log(JSON.stringify(await browser.connection.send('browser.getClientWindows', {}), null, 2));

await new Promise(resolve => setTimeout(resolve, 5000))

await page.screenshot({
  path: 'keyboard.png',
});

await browser.close();

the following code returns that a window is active but the window is not able to receive keyboard input from the operating system.

[jgraham]

What's the visibility state of these windows?

I don't know how headless usually deals with system focus, especially in the presence of multiple headless windows i.e. whether it assumes that at most one window can have (emulated) focus, or if all of them do. Maybe it differs between implementations.

[OrKoN]

What's the visibility state of these windows?

I don't know how headless usually deals with system focus, especially in the presence of multiple headless windows i.e. whether it assumes that at most one window can have (emulated) focus, or if all of them do. Maybe it differs between implementations.

so we have two implementations in Chrome: in the headless shell the visibility for all windows is faked as visible, and in the headless Chrome (which is based on the headful Chrome with all UI hidden) the visibility is determined by the protocol commands (i.e., creating a new page in the foreground will make the window appear visible to the web APIs or activating via browsingContext.activate). But in all those case, the windows do not receive user input events, the only way to send events is via an automation protocol. The Firefox implementation seems to be more similar to headless Chrome.