Bugzilla

Urlbar result payloads can contain values that aren't plain, structured-clone-safe data, so they don't survive crossing the `Urlbar` JSWindowActor boundary (with `browser.urlbar.ipc.chromeMessagePassing` on, or for a content-process `<moz-urlbar>` such as about:newtab).

Two known cases:
- `ActionsResult` class instances embedded in payloads by `UrlbarProviderGlobalActions` (consumed by `UrlbarProviderGlobalActions.getViewUpdate`, which runs in the parent process). Structured-clone drops their prototype.
- Dynamic-suggestion payloads carrying a `suggestionObject`, which fails `JsonSchemaValidator` over the wire (`Object has unexpected property 'suggestionObject'`).

Options discussed on D308752: demote `ActionsResult` to a typedef and use plain objects in payloads, or carry the view-update data in the result (as Phase 4e pre-fetches `getViewTemplate`/`getResultCommands`) so live classes stay parent-side and never need to be in the serialized payload.

This is a perf/correctness gap only on the message path; the default in-process chrome path is unaffected. Surfaced by running the urlbar mochitest-browser-chrome suite with `browser.urlbar.ipc.chromeMessagePassing` forced on.

Phase 6 of IPC Urlbar (meta bug 2049112). Phases 0-5 build the parent/child controller split and carry queries, results, and telemetry across the `Urlbar` JSWindowActor pair; this phase *proves* the whole contract end-to-end and greens up the remaining message-path-only gaps.

The message path (`browser.urlbar.ipc.chromeMessagePassing`, off by default -- also the path a content-process `<moz-urlbar>` such as about:newtab will use) isn't exercised by any default CI run. This bug adds a dedicated pref-on CI variant that runs the chrome `<moz-urlbar>` `mochitest-browser-chrome` suite over the wire, and tracks the fixes needed to get it green. The default in-process chrome path is unaffected throughout.

**Pref-on CI variant (the validation harness):** a `urlbar-ipc` test variant forces `browser.urlbar.ipc.chromeMessagePassing=true` over the urlbar suite (scoped via `MOZHARNESS_TEST_TAG`), tier 3, with a `mozinfo: urlbar_ipc` per-test escape hatch. Running it locally surfaced the gaps below.

**Gaps to green up:**

1. **Wire-safe result payloads.** Payloads can carry values that aren't plain, structured-clone-safe data, so they don't survive the actor boundary:
   - `ActionsResult` class instances embedded in payloads by `UrlbarProviderGlobalActions` (consumed by its parent-side `getViewUpdate`). Structured-clone drops their prototype, so the parent-side dynamic `getViewUpdate` builds the row from broken action data (observed as a dynamic `getViewUpdate` returning an `undefined` l10n id).
   - Dynamic-suggestion payloads carrying a `suggestionObject`, which fails `JsonSchemaValidator` over the wire (`Object has unexpected property 'suggestionObject'`).

   Options: demote `ActionsResult` to a typedef + plain objects, or carry the view-update data in the result (as Phase 4 pre-fetches `getViewTemplate`/`getResultCommands`) so live classes stay parent-side and never need serializing.

2. **Provider hooks that need content-side state.** Several providers' `onEngagement`/`onSelection`/pick hooks run in the parent but synchronously read the content-side input/view/selected element, which are null/absent on the message path:
   - `UrlbarProviderGlobalActions.onEngagement` -- `details.element.dataset.action` + `controller.view.close()`
   - `UrlbarProviderAutofill.onEngagement` -- `controller.input._setValue()` + `controller.input.startQuery()` (redo search after autofill dismissal)
   - `UrlbarProviderActionsSearchMode` -- `details.element` attributes + `documentGlobal`
   - `UrlbarProviderCalculator` -- `controller.input.view.startTail150()`
   - `UrlbarProviderAiChat` -- `controller.input.inputField` / `sapLocation` / context getters
   - `UrlbarProviderQuickSuggestContextualOptIn` -- `details.element` (feature-gated off today)

   Needs a general mechanism to route these hooks' content-side effects back to the child rather than reaching `controller.input`/`controller.view`/`details.element` directly parent-side.

3. **Smaller items:** a `viewData` deepEqual leak (message-path results carry a pre-fetched `viewData` property that breaks tests deep-comparing results), and two crashes (`browser_autocomplete_enter_race`, `browser_searchModeSwitcher_basic`).