[PSA] Support for "tab" Context in chrome.contextMenus (M150)

[Miguel Ruiz]

[PSA] Support for "tab" Context in chrome.contextMenus (M150) tl;dr: Starting in Chrome 150, the chrome.contextMenus API now supports a new tab context menu. This allows extensions to seamlessly integrate custom actions directly into the native browser tab strip's right-click menu, eliminating the need for disjointed UI workarounds.

What's Changing?

This update addresses a long-standing ecosystem request (Issue 40246822) by adding a "tab" option to the existing ContextType enum.

Key Technical Details & API Behavior

• API Update: The chrome.contextMenus API reference was updated to reflect the new "tab" context.

• Event Payload: When a custom menu item is clicked from a tab's context menu, the chrome.contextMenus.onClicked listener fires asynchronously and receives:

1. info (OnClickData): The pageUrl property is automatically populated with the URL of the tab where the right-click occurred (web_contents->GetLastCommittedURL()).

2. tab (tabs.Tab): A standard tab object representing the right-clicked tab.

• Multiple Tab Selection: If a user has multiple tabs selected (e.g., via Shift+Click), the tab argument in the event listener represents only the specific tab that was right-clicked to open the context menu. This is consistent with Firefox's existing implementation.

• Favicon Attribution: Registered extension items will automatically feature the extension's icon/favicon next to their label in the native menu for clear user attribution.
  
  

Use

• Test Your Extensions: We highly recommend testing your tab management or utility extensions in Chrome Canary (M150).

• Adopt the New Context: You can begin registering your context menus with the "tab" context:
  
  

• Provide Feedback: We encourage you to try this out and report any issues, regressions, or general feedback on crbug.com

Timeline

• Chrome 150 (Canary/Dev): Available now for testing.

• Chrome 150 (Stable): Expected release in line with the Chrome M150 release cycle.
  
  

On behalf of the Chrome Extensions team, Miguel Ruiz

Miguel Ruiz Software Engineer Chrome Accessibility migue...@gmail.com

[woxxom]

It doesn't seem to support documentUrlPatterns to indicate on which tabs I want to enable it. I suppose implementing it might pose some troubles like a lack of any URL right after a tab is created (by opening a link in a new tab) or the design+implementation hurdles with allowing "chrome://*/*" patterns, but those need to be discussed and handled gracefully and described in the documentation. Actually an additional option like "hostAccessOnly: true" might make sense to show the item only on tabs where the extension has access to the contents (one caveat is whether to do it when the access is granted only to an iframe, I guess it may be configurable as hostAccessOnly: 'main' | 'iframe' | 'any', or Chome can just put all those items inside a submenu like "Extension in child frames").

[Miguel Ruiz]

Thanks for your feedback and suggestions!

You're correct that documentUrlPatterns is not supported for the new "tab" context. This is because documentUrlPatterns filters based on the URL of the document or frame where the right-click event occurs. With the "tab" context, the click happens on the browser's tab UI element itself, which isn't part of any specific web document's context in the same way.

We understand the desire for more granular control over when extension items appear. We're initially aiming to establish a consistent behavior in line with how tab contexts are handled in other browsers.

We really appreciate you sharing these thoughtful suggestions, and we'll certainly consider them for future enhancements as we continue to evolve the API.

[Lucas]

We've been testing the new contexts: ["tab"] support in our extension (VertiTab – a tab management extension) on Chrome 150 Canary, and encountered a critical crash bug.

Issue: Chrome crashes immediately when right-clicking a tab if an extension has registered more than one context menu item for the "tab" context.

Environment:

• Chrome 150.0.7845.0 (Official Build) Canary (64-bit)
• Windows 11
• Manifest V3 extension with "contextMenus" permission

I have filed a bug report at https://issues.chromium.org/issues/514442561.

The "tab" context is an excellent addition to this API; once sub-menu functionality is supported, we look forward to fully leveraging this feature.

Thank you!

[Juraj M.]

What's the best way to detect "support" for this feature?

Using the "tabs" in <150 Chrome throws exception:

TypeError: Error in invocation of contextMenus.create(contextMenus.CreateProperties createProperties, optional function callback): Error at parameter 'createProperties': Error at property 'contexts': Error at index 0: Value must be one of action, all, audio, browser_action, editable, frame, image, launcher, link, page, page_action, selection, video.

[Juraj M.]

Never mind, for my use-case actually the good old try/catch is enough. 

Looking at my code, I should have used try/catch all along.

[woxxom]

if (chrome.contextMenus.ContextType.TAB) {

  // supported

}

or:

chrome.contextMenus.create({

  .......

  contexts: ['page', chrome.contextMenus.ContextType.TAB].filter(Boolean),

})

[Juraj M.]

Nice one! Thanks woxxom!

I've totally forgot there is an official enum like object with all types!

https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/menus/ContextType

https://developer.chrome.com/docs/extensions/reference/api/contextMenus#type-ContextType

PS:
I've requested compatibility table update on MDN to reflect "tab" support in Chrome 150:
https://github.com/mdn/browser-compat-data/issues/29704

[support]

Hi Miguel,

Thank you for the update! I can confirm that after testing on Chrome 150.0.7849.0 (Official Build) canary (64-bit), the browser crash has been successfully resolved.

However, while it no longer crashes, the context menu items are still not rendering correctly:
* Test 2 (Two flat items): Neither of the registered items shows up in the tab right-click menu.
* Test 3 & Test 4 (Parent + Children / Separator): The parent menu item appears, but the submenus (children) completely fail to display.

Since this behavior seems related to the initial implementation/fix, would you recommend that I open a new issue in the Chromium tracker to follow up on this rendering problem, or should we track it under the existing one? As I don't have much prior experience reporting bugs to Chrome, I would appreciate your guidance on the preferred workflow.

Best regards,
Lucas

[Miguel Ruiz]

Hi Lucas, thanks for reporting the bug, It was being addressed and the fix will be included as part of the same release as the new API (M150)