Problem Statement:

In Widget V2, the active tab (Page Help or Knowledge Base) is controlled internally by the widget's own state, and only the active tab's content is mounted in the page at any time. Customers who need the widget to consistently open to, or return to, a specific tab (most commonly the Knowledge Base tab) have no supported, official way to do this. The only current workaround is a custom script that simulates a click on the tab's DOM element and watches for changes with a MutationObserver, an approach that depends on internal DOM structure (element IDs, class names) that isn't a documented or guaranteed public contract, and that has already broken once when the widget moved from V1 to V2.

Suggested Enhancement:

Add a supported tab-switching command to the existing postMessage API and its mw() wrapper, alongside the existing show, hide, and toggle commands — for example mw('showTab', { tab: 'knowledgeBase' }) or an equivalent postMessage method. This would let customers switch tabs deliberately and reliably without relying on internal DOM structure.

Customer Benefit:

Removes the need for fragile, DOM-dependent custom scripts and MutationObservers to control tab state. Gives customers a stable integration point that won't break on future internal architecture changes to the widget, the same way show/hide/toggle already provide that stability for opening and closing the widget.