Disable-suggest tracking still built its Glean event parent-side at
pref-toggle time, re-deriving the interaction type and action from the
engagement's DOM event and reading the live input via the engagement data.
Neither is available to a message-path parent controller, which reaches the
input over the actor, so the disable event never recorded there.
Build the disable candidate content-side when a Suggest result is engaged or
abandoned -- the same way bounce is tracked -- and ship the built event. The
parent holds it and, if the user turns Suggest off within the threshold,
records it through the shared fill-and-record path, needing neither the DOM
event nor the live input.
Building it content-side also retires the parent-side disable check, which was
the last thing reading the raw visible results the engagement payload shipped
over the wire, so that now-dead plumbing comes out here too. The one thing to
check on that: it's the shipped copy that goes -- the visible results the Glean
event is built from are untouched.
Behavior-neutral on the direct path: the recorded Glean events are identical.
Differential Revision: https://phabricator.services.mozilla.com/D310537
Dão Gottwald
fe375cedeb