Discussion: drop new Firefox notice, rely on existing notice + refetch-on-focus

[ivan-ottinger]

Related issues

• Related to Linux: auto-trust Firefox profiles and surface in-app cert notice #3472

Context

This is a draft companion to #3472 to make the alternative I sketched in this review thread easier to look at as code. It's not a merge candidate — it targets #3472's branch so the diff shows exactly what I'd remove and what I'd keep relative to that PR. Close it once we agree on a direction.

What this PR proposes

Keep the substantive fix from #3472 (auto-importing the Studio CA into existing Firefox profile NSS DBs, and including Firefox profiles in the trust check). Drop the new in-app Firefox notice and the IPC/detection plumbing that exists only to feed it.

Both PRs benefit from refetchOnFocus: true (already set on certificateTrustApi since the monorepo restructure) + setupListeners(store.dispatch) (already wired in stores/index.ts). When the user opens Firefox for the first time after clicking Trust, the next focus event re-runs isRootCATrusted(), the freshly-created profile DB no longer satisfies areAllFirefoxProfilesTrustedLinux, and trust flips back to false. In #3472 both the existing notice and the new Firefox-specific notice reappear; in this alternative only the existing notice does. One more Trust click imports into the new profile with no sudo prompt (system bundle install is skipped when the cert is already in /etc/ssl/certs).

Proposed Changes

Removed (only exists to feed the new notice):

• apps/studio/src/lib/detect-linux-browsers.ts + its test
• getLinuxBrowserCertSupportStatus IPC handler in ipc-handlers.ts
• Preload binding in preload.ts
• getLinuxBrowserCertSupportStatus RTK Query endpoint + hook in certificate-trust-api.ts
• docsSslLinuxFirefox in get-localized-link.ts (rely on the existing docsSslInStudio page with a Linux/Firefox subsection)
• The Firefox notice + isLinux and useGetLinuxBrowserCertSupportStatusQuery imports in content-tab-settings.tsx

Kept (the substantive fix from #3472):

• importCAIntoFirefoxProfilesLinux, areAllFirefoxProfilesTrustedLinux, getLinuxFirefoxProfileDbDirs in tools/common/lib/linux-trust-store.ts
• The composition in isRootCATrusted() and the import call in trustRootCA()
• All 12 trust-store tests

Net diff vs. #3472: −128 lines, +4 lines.

Why I think this is worth considering

• Less code to maintain. −128 / +4 line net delta, with the Firefox auto-import behavior preserved unchanged.
• Avoids misleading copy in the "no profile yet" state. Linux: auto-trust Firefox profiles and surface in-app cert notice #3472's Firefox-specific notice fires whenever firefoxDetected && !isCertificateTrusted, including when Firefox is installed but no profile exists yet. In that state the copy says "import it manually to avoid the security warning" even though there's nothing to import into — and when the user does open Firefox later, the auto-import will handle it for them on the next Trust click. The alternative defers to the existing notice, which makes no Firefox-specific promise it can't keep.
• One notice instead of two stacked notices. When Firefox is detected and the cert is untrusted, Linux: auto-trust Firefox profiles and surface in-app cert notice #3472 renders two notice paragraphs in the same row. The alternative renders one, with the Firefox specifics living in the existing SSL docs page under a Linux subsection.

Testing Instructions

The following were verified end-to-end on a Linux VM with Snap Firefox installed:

• Trust click — system bundle (pkexec) + Chromium NSS + existing Snap Firefox profile all imported.
• Trust state regresses (cert removed from Firefox profile) → existing notice + Trust link reappear when Studio regains focus.
• Subsequent Trust click runs without sudo prompt; only NSS imports execute.
• Firefox installed but no profile yet → trust check stays vacuously true, notice stays hidden.
• Firefox opened for the first time after Trust click → existing notice reappears on focus; one more Trust click silently imports the cert into the freshly-created profile.
• All unit tests pass (npx vitest run tools/common/lib/tests/linux-trust-store.test.ts — 12/12; full studio suite 82 files / 639 tests).

Findings outside this PR's scope

During testing we hit a pre-existing bug in the trust check that's independent of which notice approach lands: certutil -L -d sql:<db> -n "WordPress Studio CA" fails to verify trust when the cert exists in the NSS DB under a different nickname — e.g., the <CN> - <Org> pattern Firefox uses when a user manually imports via the certificate manager. NSS dedupes by certificate content on -A, keeping the existing nickname, so the cert ends up trusted but Studio's UI continues to nag. Pattern was introduced in #3268 (Chromium NSS) and inherited by #3472 (Firefox profiles, where the collision is more likely). To be filed and fixed separately.

Pre-merge Checklist

• N/A — discussion draft, not for merge.