mirror of
https://github.com/mozilla-firefox/firefox
synced 2026-08-10 11:48:50 +00:00
The message path (`browser.urlbar.ipc.chromeMessagePassing`) is off by default, so nothing in CI exercises the wire contract the chrome `<moz-urlbar>` instances are meant to prove out. Add a `urlbar-ipc` test variant that forces the pref on and runs the urlbar mochitest-browser-chrome suite over the wire, scoped via `MOZHARNESS_TEST_TAG: [urlbar]` (the urlbar manifests already tag their tests) so it doesn't run the whole browser-chrome suite. A `mozinfo: urlbar_ipc` flag lets an individual test opt out (`skip-if = urlbar_ipc`) when it must stay on the direct path. Attached to `mochitest-browser-chrome` as `urlbar-ipc` (Windows/macOS) and `webrender-sw+urlbar-ipc` (Linux, under software WebRender), on opt, tier 3. Windows and Linux run on autoland and mozilla-central. macOS runs on mozilla-central only: on the modern aarch64 platform M(bc) is scheduled solely on the shippable build, which isn't produced on autoland. Four tests assert the switcher's icon in a window they open themselves, which the message path can't satisfy while bug 2059513 is open: the engine store's snapshot arrives from the parent, so the fallback icon shows until then. Rather than skip them outright they pin the pref off for the window they open, so they keep running and only their transport changes. test_keyword_disabled's searchbar assertion also had to move to that window -- it read the l10n id off the test's own window, unlike the urlbar assertion beside it, so pinning the pref would otherwise not have reached it. The private-engine icon is one of the four. It is timing-dependent and doesn't reproduce locally, so it survived an earlier pref-on run that appeared to clear it; a try run of this variant fails it on Linux. Differential Revision: https://phabricator.services.mozilla.com/D309861