2054070 - [IPC Urlbar] Bake the view's per-result data into UrlbarResult for the message path

Status: ASSIGNED

(Firefox :: Address Bar, task)

Description

[Dão Gottwald [:dao]]

Broken out from Bug 2051959.

The view's synchronous per-result data (a dynamic result's view template and a result's menu commands) is fetched from the result's provider on demand, which the actor message path can't do when the provider lives in another process. Compute it eagerly when the result is finalized and store it on UrlbarResult (serialized by toWire()/fromWire()) so the view reads it synchronously on both transports, replacing the earlier pre-fetched non-enumerable viewData expando cache.

Comment 1

[Dão Gottwald [:dao]]

Attachment: Bug 2054070 - [IPC Urlbar] Bake the view's per-result data into UrlbarResult. r?mbeier!

The view's synchronous per-result data -- a dynamic result's view template and
a result's menu commands -- was fetched from the result's provider on demand,
which the message path can't do when the provider lives in another process. It
worked around this by pre-fetching the data with each QueryResults notification
and stashing it on a non-enumerable viewData expando that the view read back.

Compute it eagerly instead, when the result is finalized in
UrlbarProvidersManager, and store it on UrlbarResult as viewTemplate and
commands. Both are serialized by toWire()/fromWire(), so the view reads them
synchronously on both transports without a round-trip or the expando (and its
deepEqual/serialization hazard). getViewUpdate stays dynamic and round-trips.

Static per-result data a provider parked in getViewUpdate moves to the baked
template too: RealtimeSuggestProvider set the result's navigation url/query on
the row's dataset from getViewUpdate, so on the message path a click resolved no
URL until that async update landed. Baking the dataset into getViewTemplate makes
it present when the row is built; only genuinely dynamic per-item data (text,
images, aria group) stays in getViewUpdate.

Because the commands are baked, a provider that changes them while the result
stays in the view must refresh the baked value, not just drop the view's command
cache -- reaching the "show less frequently" cap removes that command, and the
stale baked commands would otherwise keep it. Consolidate the show-less-frequently
handling each suggestion provider inlined into a shared
SuggestProvider.handleShowLessFrequently that re-bakes the result's commands, so
the refresh lives in one place rather than being repeated (and missable) per
provider.

Comment 2

[Dão Gottwald [:dao]]

Attachment: Bug 2054070 - [IPC Urlbar] Keep the message-path view-data cache off the result's enumerable shape. r?daleharvey,mbeier

The pre-fetched per-result view data (viewTemplate/resultCommands) is
attached to each reconstructed result on the message path so the view can read
it synchronously. Attaching it as a plain property left it enumerable, so it
leaked into result comparisons and serialization -- e.g. tests that deepEqual
a view result against an expected one saw a spurious viewData key. Define it
non-enumerable; the proxy still reads it by direct access.

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/17c7ced2a8b8
https://hg.mozilla.org/integration/autoland/rev/cca71088ffb9
[IPC Urlbar] Keep the message-path view-data cache off the result's enumerable shape. r=daleharvey