Make the Site Information panel an experimental opt-in#20
Merged
Conversation
The panel's plugin/theme detection relies on asset-path inference, which is inherently lossy — sites with multiple asset paths per plugin show duplicates, mu-plugins and drop-ins leak through as false positives, and the result confidently presents data that is sometimes wrong. Better to gate this behind explicit opt-in than to present it as a first-class feature on a 1.0 release. The toggle lives in a new Experimental section on the options page, off by default. The popup reads the new `siteInfoEnabled` global pref through the existing `usePrefs` hook and gates the `<SiteInfoPanel>` render on it. README updated to describe the options page surface and the experimental section. Closes #4 by reframing the panel's accuracy gap as an explicit expectation rather than a bug to chase.
This was referenced Jun 6, 2026
jakemgold
added a commit
that referenced
this pull request
Jun 7, 2026
…ale comment (#23) ## Summary Three small follow-ups from a read-only sweep against #18 / #20. ### 1. Safari Resources `options/` was left untracked (P1) The Xcode project file (\`project.pbxproj\`) added in #18 references \`Resources/options/\`, but the three files inside that folder were never staged. A fresh clone hits the same "Unable to find options/options.html" error we saw before #18 fixed the Xcode side — just from the other direction. Stage them. ### 2. Plugin URI scheme validation (P2) \`lib/site-info.js\` was happily forwarding whatever \`plugin_uri\` the REST response carried. That value comes from a plugin's own "Plugin URI" header — site-authored, and attacker-controllable when a site runs untrusted plugins. \`SiteInfoPanel\` then opened those URIs in new tabs. Add \`safePluginUri()\` that rejects anything outside \`http:\` / \`https:\`. The existing \`wordpress.org/plugins/{slug}/\` fallback in \`SiteInfoPanel\` covers the rejected cases. A new \`[23]\` smoke scenario covers javascript:, data:, malformed, and empty. ### 3. Stale comment in \`lib/early.js\` (P3) The header doc still said the admin bar default was hidden. The per-origin default flipped to shown in #17 and the global override landed in #18. Rewrite the paragraph so future maintainers don't follow the wrong mental model. ## Test plan - [x] \`npm run build:safari\` — clean - [x] \`npm test --prefix test\` — all green (existing scenarios + new [23]) - [ ] Fresh clone + \`npm install\` + open the Safari project in Xcode without running \`build:safari\` first — should no longer error on missing options page resources Credit: findings from a Codex read-only sweep.
itzmekhokan
pushed a commit
to itzmekhokan/browser-extension
that referenced
this pull request
Jun 7, 2026
…ale comment Three small follow-ups from a read-only sweep of WordPress#18 + WordPress#20: 1. The Safari Resources mirror of `options/` was never staged in WordPress#18. Xcode's project file already references `Resources/options/` (added in WordPress#18), but the files themselves were left untracked, so a fresh clone hits "Unable to find options/options.html in the extension's resources" — the same error pattern we hit before the Xcode project was updated, just from the other direction. Stage the three files so Xcode resolves them out of the box. 2. The Site Information panel happily opened whatever `plugin_uri` the REST response carried. That value comes from a plugin's own "Plugin URI" header — site-authored, attacker-controllable when sites run untrusted plugins. Add `safePluginUri()` in `lib/site-info.js` that rejects anything other than `http:` / `https:`; SiteInfoPanel's existing fallback to `wordpress.org/plugins/{slug}/` covers the rejected cases. New `[23]` smoke scenario covers javascript:, data:, malformed, and empty inputs. 3. The header comment in `lib/early.js` still said the admin bar default was hidden. That was the original behavior, but the per-origin default flipped to shown in WordPress#17 and the global override added in WordPress#18. Rewrite the doc paragraph so future maintainers don't follow the wrong mental model. Reported by Codex sweep against WordPress#18 / WordPress#20.
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
1 participant
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.
Summary
The Site Information panel's plugin/theme detection relies on asset-path inference, which is inherently lossy. The same issue (#4) covers the symptom — duplicates from plugins that enqueue multiple asset paths, false positives from mu-plugins and drop-ins, slugs that don't match actual plugin folder names. None of those are bugs to fix; they're the nature of frontend-only inference.
For a 1.0 release, "show confidently-wrong data by default" is the wrong trade. Gate the panel behind an explicit opt-in on the options page, framed as experimental.
Changes
The panel's existing source code is untouched. Users who turn it on get exactly what shipped before.
Test plan
Closes #4.