Add API to switch focus from sidePanel to main document to enable accessibility features

[SpaceK33z]

Description:
Interacting with the extension’s side panel (chrome.sidePanel) shifts focus away from the main webpage, and there is no way to programmatically return focus to the main document. This limitation makes it impossible to implement some features related to accessibility.

Context:
Managing focus between the main document and the side panel's document within the same tab is essential for accessibility.
With proper focus management, the user can select something from the side panel, and the side panel can simulate certain events that only work when the main document is in focus.

Currently, extensions can switch focus between tabs, but not within the main document and side panel document.

Proposed Solution:
Introduce a new API that allows extensions to programmatically shift focus from the side panel back to the main document.

[hanguokai]

In contrast, when the side panel is opening, the focus remains on main webpage and does not move to the side panel, which makes some functions impossible. For example, a typical user requirement is to focus on the input box when the side panel opens, so that the user can input something immediately.

So I hope there is a way to solve the problem of bidirectional focus movement.

[oliverdunk]

We discussed this during an in-person triage meeting at TPAC. We are aligned on the following:

• The behavior @hanguokai mentioned seems like a bug. We should look at ensuring the side panel takes focus from the page when it is first opened regardless of the mechanism used to open it.
• We are supportive of implementing a tabs.focus() method which would return focus to the web content. This would close the popup if open and move focus away from other parts of the UI such as the address bar.

[hanguokai]

We are supportive of implementing a tabs.focus() method which would return focus to the web content. This would close the popup if open and move focus away from other parts of the UI such as the address bar.

A typical case comes to mind. When opening a new tab page(by shortcut or mouse), the focus is on the address bar for user input. Now the new tab page extension would like to call tabs.focus() to move the focus into the NTP for its own searching or shortcut function. Do browsers allow this behavior?

There may be other risks of abuse.

[Rob--W]

I raised that exact question and the answer is that the content area would be focused indeed. The meeting notes for the TPAC 2024 meeting will be published soon, here is the relevant excerpt:

• [rob] If the address bar was focused and you call this method, what happens?
• [devlin] It focuses the main content in the tab (document tree in Chrome, webview in Safari) - whatever was the active frame is focused.

[jpc-ae]

Any movement on this?

[Diego1149]

+1, this is blocking one of our launches.

[qupig]

We are supportive of implementing a tabs.focus() method which would return focus to the web content. This would close the popup if open and move focus away from other parts of the UI such as the address bar.

tabs.focus() would be nice, but I think there is a need for a capability to enable the extension to switch focus arbitrarily.

Here is an example, hoping that the focus will remain in sidebar:

A common use of sidebar is to display a list of vertical tabs, and clicking on one of those tabs invokes browser.tabs.update(tabId, { active: true }); to activate the corresponding tab.

However, currently after calling tabs.update, the focus will auto switch to the tab, causing sidebar to lose focus.

If I want to use the keyboard up and down keys in the sidebar to switch between different tabs, this is currently NOT possible.

I'm sure there are plenty of other situations there that would like to keep the focus in the sidebar after switching tab.

So we need a method to prevent the tabs.update call from shifting focus, or we also need a sidebar.focus() method as well.

Now the new tab page extension would like to call tabs.focus() to move the focus into the NTP for its own searching or shortcut function. Do browsers allow this behavior?
There may be other risks of abuse.

I support the extension having that ability.

The newtab page implemented by the extension can implement its own omnibox, and may be richer or have different features than the browser's own.

If this is the user expects to replace the default address bar focus, an extra click will disrupt the user workflow.

Preventing abuse is something extensions should provide relevant options for.
Otherwise the user can refuse to use the extension.

[remusris]

I'm having this exact same issue and yes it would be optimal to change the default so that the sidepanel gets into focus upon trigger or at an option to focus the sidepanel when opening it. There's only two workarounds I'm aware of, on Windows/Linux you can press Shift + F6 to change focus to the sidepanel (F6 is the reverse direction) while on mac is Command + Option + Arrow Up / Arrow Down but in most cases it seems that Command + Option + Arrow Up will get you there without needing to highlight the address bar. The other alternative is just to use the popup window for a single function if you really need to have autofocus working and trigger chrome.actions.openPopup().

Below is also a link pertinent to this dialogue
https://groups.google.com/a/chromium.org/g/chromium-extensions/c/nb058-YrrWc