You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hotfix for #2991. extensionManagement ships as preview during the phased rollout. The catalog read compared state strings directly and accepted only enabled and internal, so preview read as off, the catalog came back empty, and every curated extension rendered the "Unsupported extension" pill instead of "Add to DuckDuckGo". Caught on Canary during Windows testing.
The same check was wrong in the other direction: ignoring the platform meant internal counted as on for public builds, which would offer a working install button to a browser that cannot install extensions. That is a fail-open in a feature built to fail closed.
readCuratedCatalog now takes the state check as a parameter, and the feature passes ConfigFeature#_isStateEnabled. Both states resolve against the build's platform flags rather than being matched as bare strings, and there is no second copy of the state logic left to drift.
getFeatureSettingEnabled cannot serve here: parseFeatureSettings copies only a feature's settings, so a sub-feature's state and the features map are absent, and the enabled-features filter also applies domain exceptions, which must not decide whether the browser can install extensions.
On a Windows build with extensionManagement and curatedExtensions at preview: a curated extension detail page (Bitwarden) shows "Add to DuckDuckGo" rather than "Unsupported extension"
Worth confirming before this is relied on:preview only takes effect if platform.preview === true in the Canary build. That flag is set Windows-side, and we already know internal comes from being logged in as an internal user rather than from the release channel. Setting the state to enabled bypasses platform flags entirely, so that working is not evidence preview will.
Checklist
Please tick all that apply:
I have tested this change locally
I have tested this change locally in all supported browsers
This change will be visible to users
I have added automated tests that cover this change
I have ensured the change is gated by config
This change was covered by a ship review
This change was covered by a tech design
Any dependent config has been merged
Note
Medium Risk
Changes fail-closed install-button gating and catalog source selection for extension management; wrong platform flags could still hide or expose install affordances incorrectly.
Overview
Fixes curated Web Store install UI treating preview rollout state as off and internal as on regardless of build flags.
readCuratedCatalog now receives the same platform-aware gate as ConfigFeature#_isStateEnabled (via an injected isEnabled callback) instead of matching only enabled/internal strings. That restores catalog reads when extensionManagement / curatedExtensions ship at preview, and stops public builds from treating internal as installable.
On internal builds (platform.internal), the helper prefers catalogInternal over catalog (replacing the public list, with safe fallback when internal catalog is missing or invalid). Docs and unit tests cover state gating, internal catalog selection, and use real isStateEnabled in specs.
Reviewed by Cursor Bugbot for commit fb1e720. Bugbot is set up for automated code reviews on this repo. Configure here.
extensionManagement ships as 'preview' during a phased rollout. The catalog
read compared state strings directly and accepted only 'enabled' and
'internal', so 'preview' read as off, the catalog came back empty, and every
curated extension rendered the "Unsupported extension" pill. Caught on
Canary during Windows testing.
The same check was wrong in the other direction too: ignoring the platform
meant 'internal' counted as on for public builds, which would offer a
working install button to a browser that cannot install extensions. That is
a fail-open in a feature built to fail closed.
readCuratedCatalog now takes the state check as a parameter and the feature
passes ConfigFeature#_isStateEnabled, so both states resolve against this
build's platform flags instead of being matched as bare strings, and there
is no second copy of the state logic to drift.
getFeatureSettingEnabled cannot serve here: parseFeatureSettings copies only
a feature's settings, so a sub-feature's state and the features map are
absent, and the enabled-features filter also applies domain exceptions,
which must not decide whether the browser can install extensions.
No browser API overrides or prototype changes. Scope is limited to Chrome Web Store DOM when patchWebstore is enabled. Replacing the local isStateOn() string comparison with the injected isEnabled callback is a config-gating fix only.
injected/src/features/chrome-webstore-patching.js
405
info
Positive UX fix on preview builds. The removed isStateOn() treated preview as off, so the catalog read as empty and every curated extension showed the "Unsupported extension" pill on Canary (documented in the PR). Passing _isStateEnabled restores correct install/remove pill behavior during phased rollout.
injected/docs/chrome-webstore-patching.md
41
info
Documentation accurately describes the platform-flag contract. No viewport, MutationObserver, or SPA-navigation behavior changes in this diff.
Positive config-trust fix. Old isStateOn() treated internal as enabled on all builds regardless of platform.internal. That could reveal a working install button on public builds that cannot install extensions — a fail-open UX/security boundary violation. The injected isEnabled callback respects platform.internal / platform.preview via isStateEnabled().
injected/src/features/chrome-webstore-patching.js
405
info
Correctly delegates to ConfigFeature#_isStateEnabled rather than reimplementing state logic — consistent with computeEnabledFeatures() and other features. No messaging, nativeData, captured-globals, or iframe-access changes.
Tests now pin the real isStateEnabled contract via { internal: true } instead of a stand-in. See inline comment on missing preview / no-flag coverage.
Risk Level
Medium Risk — Config-gating logic change in injected Chrome Web Store feature code; no API overrides or messaging changes, but it affects which install buttons are revealed based on platform flags.
Recommendations
Add unit tests for the two fixed regressions (see inline comment on chrome-webstore-patching.spec.js):
preview state + { preview: true } → catalog returned
internal state + no platform flags → [] (the public-build bug)
Optional: Integration test exercising a preview-state bundled config on a mock preview platform args object, if the integration harness supports platform flag injection.
Local validation: 33/33 chromeWebstorePatching helpers unit specs pass on Node 24.
Windows offers a wider set internally (1Password and LastPass alongside
Bitwarden) while the public catalog stays at Bitwarden only, so internal
users read curatedExtensions.settings.catalogInternal in place of catalog.
It replaces the public list rather than extending it, matching the native
behaviour.
Absent on older configs, so a missing or malformed catalogInternal falls
back to catalog. That is the narrower list, so the fallback cannot widen
what an internal user is offered, and internal users keep working against
config that predates the field.
Internal-ness comes from platform.internal, which native passes in at init;
it is not the feature state, so it is read directly rather than through
_isStateEnabled.
The reason will be displayed to describe this comment to others. Learn more.
Stale comment
Web Compatibility Assessment
File
Lines
Severity
Finding
injected/src/features/chrome-webstore-patching.js
404–406
warning
getCuratedExtensionIds() does not pass isInternal to readCuratedCatalog. The helper and docs now select catalogInternal on internal builds, but the feature always uses the default isInternal = false, so production code never reads catalogInternal. Internal builds will see the public catalog instead of trial extensions — the opposite of the documented native behaviour.
Replacing isStateOn() with injected isEnabled (backed by _isStateEnabled / isStateEnabled) correctly handles preview and internal states against platform.preview / platform.internal. Fixes the Canary regression where preview state fell through to false and every curated extension showed "Unsupported extension".
Tests now use real isStateEnabled and cover catalogInternal paths. Still missing explicit preview + { preview: true } and internal state + no platform flags → [] cases that pin the original shipped bugs.
injected/docs/chrome-webstore-patching.md
41–43
info
Documentation accurately describes state gating and catalogInternal semantics.
No API overrides, DOM manipulation changes, prototype patches, or timing/race regressions in this delta.
Delegating state checks to _isStateEnabled closes the prior fail-open path: old isStateOn() treated internal as on regardless of platform.internal, which could expose a working install button on public builds without native extension support.
injected/src/features/chrome-webstore-patching.js
405
info
/** @type {any} */ cast on catalog state before _isStateEnabled — type-safety gap at the install-gating boundary, not a runtime bypass (state values are plain strings from bundled config).
No changes to captured globals, messaging, message bridge, origin validation, postMessage, or config trust boundaries. No nativeData leakage vectors.
Risk Level
Medium Risk — Config-gated catalog resolution logic with platform-aware state checks; no API shims or messaging changes, but incorrect catalog selection affects install-button visibility on the Chrome Web Store.
Recommendations
error — Wire platform.internal through in getCuratedExtensionIds():
Fixes two review findings on #3029.
getCuratedExtensionIds never passed isInternal, so it defaulted to false
and catalogInternal was dead code: internal builds kept reading the public
catalog and trial-only extensions still showed as unsupported. The earlier
commit claimed this call site but never touched it.
Also drops the any cast on the state value. readCuratedCatalog now narrows
config values through asFeatureState, so an unrecognised state reads as
undefined and fails closed rather than being asserted into the type, and
the caller passes state through untouched.
No test covers the wiring yet. A fixture carrying catalogInternal fails
schema validation against the pinned privacy-configuration, which declares
catalog only, so that test has to wait for the schema change to merge and
the pin to be bumped.
The reason will be displayed to describe this comment to others. Learn more.
Injected PR Evaluation: Web Compatibility & Security
Re-assessed on synchronize (ea5c2afe, 2026-09-09). The prior warning about missing isInternal wiring is resolved — getCuratedExtensionIds() now passes this.platform?.internal === true.
No browser API overrides or prototype changes. Scope remains Chrome Web Store DOM patching when patchWebstore is enabled. Replacing the local isStateOn() string comparison with an injected isEnabled callback correctly enables preview when platform.preview === true — fixes the shipped Canary regression where every curated extension showed the "Unsupported extension" pill.
injected/src/features/chrome-webstore-patching.js
407–408
info
catalogInternal selection is now wired end-to-end. Internal builds read the trial catalog; public builds continue reading catalog. Fail-closed semantics preserved: unreadable config → [] → unsupported pill.
An explicit catalogInternal: [] (empty array) is treated as present and will not fall back to catalog. Docs describe absence/malformed fallback only. Confirm this matches native extensionManagement behaviour; otherwise an empty internal list could hide all extensions on internal builds.
Tests now exercise catalogInternal selection and use the real isStateEnabled helper. Still no explicit cases pinning the two shipped regressions: preview state with { preview: true }, and internal state with no platform flags → []. isStateEnabled is covered in utils-properties.spec.js, but direct readCuratedCatalog cases would guard against future reverts of the isEnabled injection.
Positive: Delegating state checks to _isStateEnabled closes the fail-open path where state: 'internal' was treated as on regardless of platform.internal. Public builds no longer risk surfacing a working install button for a browser that cannot install extensions.
Positive:catalogInternal replaces (not extends) catalog, and malformed/absent catalogInternal falls back to the narrower public list — cannot widen what public users are offered.
All changed files
—
info
No changes to captured globals, messaging, message bridge, API overrides, postMessage, or load()-time logic. bundledConfig is native-supplied; page scripts cannot influence catalog resolution.
Risk Level
Medium Risk — platform-aware config state gating and internal-catalog selection affect Chrome Web Store install-button visibility, but no browser API shims, messaging, or security-boundary changes.
Optional (info): Confirm empty-array catalogInternal behaviour with native; add a fallback or test if native treats [] as absent.
Ready to merge from a web-compat/security perspective — the isInternal wiring gap from the prior review is closed. 14/14 readCuratedCatalog specs pass locally.
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
semver-patchBug fix / internal — no release needed
3 participants
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.
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
Asana Task/Github Issue: Fix curated extension catalog not reading when extensionManagement is set to preview
Description
Hotfix for #2991.
extensionManagementships aspreviewduring the phased rollout. The catalog read compared state strings directly and accepted onlyenabledandinternal, sopreviewread as off, the catalog came back empty, and every curated extension rendered the "Unsupported extension" pill instead of "Add to DuckDuckGo". Caught on Canary during Windows testing.The same check was wrong in the other direction: ignoring the platform meant
internalcounted as on for public builds, which would offer a working install button to a browser that cannot install extensions. That is a fail-open in a feature built to fail closed.readCuratedCatalognow takes the state check as a parameter, and the feature passesConfigFeature#_isStateEnabled. Both states resolve against the build's platform flags rather than being matched as bare strings, and there is no second copy of the state logic left to drift.getFeatureSettingEnabledcannot serve here:parseFeatureSettingscopies only a feature'ssettings, so a sub-feature'sstateand thefeaturesmap are absent, and the enabled-features filter also applies domain exceptions, which must not decide whether the browser can install extensions.Testing Steps
npm exec --workspace=injected playwright -- test --project=windows chrome-webstore-patching --reporter=list(34 specs)npm exec --workspace=injected jasmine -- --config=unit-test/config.json(1222 specs)npm run lintextensionManagementandcuratedExtensionsatpreview: a curated extension detail page (Bitwarden) shows "Add to DuckDuckGo" rather than "Unsupported extension"Worth confirming before this is relied on:
previewonly takes effect ifplatform.preview === truein the Canary build. That flag is set Windows-side, and we already knowinternalcomes from being logged in as an internal user rather than from the release channel. Setting the state toenabledbypasses platform flags entirely, so that working is not evidencepreviewwill.Checklist
Please tick all that apply:
Note
Medium Risk
Changes fail-closed install-button gating and catalog source selection for extension management; wrong platform flags could still hide or expose install affordances incorrectly.
Overview
Fixes curated Web Store install UI treating
previewrollout state as off andinternalas on regardless of build flags.readCuratedCatalognow receives the same platform-aware gate asConfigFeature#_isStateEnabled(via an injectedisEnabledcallback) instead of matching onlyenabled/internalstrings. That restores catalog reads whenextensionManagement/curatedExtensionsship atpreview, and stops public builds from treatinginternalas installable.On internal builds (
platform.internal), the helper preferscatalogInternalovercatalog(replacing the public list, with safe fallback when internal catalog is missing or invalid). Docs and unit tests cover state gating, internal catalog selection, and use realisStateEnabledin specs.Reviewed by Cursor Bugbot for commit fb1e720. Bugbot is set up for automated code reviews on this repo. Configure here.