Raised in review on #189 and correct: assertPanelPageLoads navigates straight to the packaged page, so the browser release gate never clicks the toolbar action or observes the side panel opening. A build with a valid static side_panel declaration but a broken setPanelBehavior execution passes as long as panel.html paints.
Why it was not fixed there
Playwright cannot click a Chrome extension's toolbar action. The action button lives in browser chrome, not in any page, and is outside the automation surface. There is no way to assert "the panel opened from a click" from the harness that gate runs in.
Rather than assert something easier and call it covered, #189 verifies what it can:
- the packaged manifest binds
side_panel.default_path to panel.html
- the action declares no popup, since a popup takes precedence over the click event
- the popup entrypoint is absent, so nothing can reclaim the click
openPanelOnActionClick is present in the background source
Together those make a dead toolbar button unlikely. They do not make it impossible, and the gap should stay visible.
What would actually close it
Options, none free:
- A CDP-driven check outside Playwright's page API that can reach browser chrome.
- An extension-side assertion: have the panel record that it was opened via the action, and check that record. Moves the proof inside the extension, where the harness can see it.
- Accept it as a manual live-QA step and record it in the release checklist rather than pretending automation covers it.
Option 2 is the only one that stays automated, and it costs a new persisted signal, which is itself an ask-first change.
Until then
The live check is: load the built extension, click the toolbar icon, confirm the side panel opens. It belongs in live QA, not in the automated gate, and this issue exists so that is a recorded decision rather than an omission.
Raised in review on #189 and correct:
assertPanelPageLoadsnavigates straight to the packaged page, so the browser release gate never clicks the toolbar action or observes the side panel opening. A build with a valid staticside_paneldeclaration but a brokensetPanelBehaviorexecution passes as long aspanel.htmlpaints.Why it was not fixed there
Playwright cannot click a Chrome extension's toolbar action. The action button lives in browser chrome, not in any page, and is outside the automation surface. There is no way to assert "the panel opened from a click" from the harness that gate runs in.
Rather than assert something easier and call it covered, #189 verifies what it can:
side_panel.default_pathtopanel.htmlopenPanelOnActionClickis present in the background sourceTogether those make a dead toolbar button unlikely. They do not make it impossible, and the gap should stay visible.
What would actually close it
Options, none free:
Option 2 is the only one that stays automated, and it costs a new persisted signal, which is itself an ask-first change.
Until then
The live check is: load the built extension, click the toolbar icon, confirm the side panel opens. It belongs in live QA, not in the automated gate, and this issue exists so that is a recorded decision rather than an omission.