Force custom menus in Integrated Browser smoke tests - #328969
Merged
Merged
Conversation
The suite drives the browser toolbar overflow and Add to Chat menus through HTML locators (.monaco-menu-container). On macOS, stable builds default window.menuStyle to 'native' while insiders default to 'inherit', so those menus render as native OS menus in stable and the locators never resolve. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Contributor
There was a problem hiding this comment.
Pull request overview
Ensures Integrated Browser smoke tests consistently use DOM-rendered menus across build qualities.
Changes:
- Batch-writes browser test settings.
- Forces
window.menuStyletocustom.
Show a summary per file
| File | Description |
|---|---|
test/smoke/src/areas/browserView/browserView.test.ts |
Configures custom menus during suite setup. |
Review details
- Files reviewed: 1/1 changed files
- Comments generated: 0
- Review effort level: Balanced
Contributor
Screenshot ChangesBase: Changed (2)
|
| Before | After |
|---|---|
 |
 |
chat/input/chatInput/VoiceModeConnecting/Light
| Before | After |
|---|---|
 |
 |
hediet
approved these changes
Aug 4, 2026
benibenj
added a commit
that referenced
this pull request
Aug 4, 2026
…ies (#328983) The suite drives the browser toolbar overflow and Add to Chat menus through HTML locators (.monaco-menu-container). On macOS, stable defaults window.menuStyle to 'native' while insiders defaults to 'inherit', so those menus render as native OS menus in stable and the locators never resolve. Pin the setting to 'custom' for the suite, seeded on disk before startup. Writing it at runtime instead would make SettingsChangeRelauncher pop a modal 'restart to take effect' dialog on Windows/Linux, blocking the workbench. Ports #328969 and #328972 from release/1.132 to main. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The
Integrated Browsersmoke suite drives the browser toolbar overflow menu (Site Permissions) and theAdd to Chatmenu through HTML locators:On macOS the default for
window.menuStyleis quality dependent:So a stable build renders those menus as native OS menus, which never create a
.monaco-menu-containerelement, while insiders renders custom HTML menus. Building both qualities from the samerelease/1.132commit reproduces this: the suite passes on insiders and fails on stable withThe follow-on
"after each" hooktimeout is a cascade: the native menu stays open, so closing the browser page inafterEachnever completes. Retries cannot help because the mismatch is deterministic per quality.This pins
window.menuStyletocustomfor the suite so the menu-driving helpers hit the DOM menus they assert on, regardless of build quality. The suite covers browser actions, not native menu integration.Validation runs in CI.