Previously we just checked every newly sideloaded add-on to decide whether to
offer it to the user for opt-in. This adds a new "seen" property (naming could
be better if you have other suggestions) which tracks whether we've ever shown
the opt-in UI for the add-on. It defaults to true for all add-ons and is only
set to false for sideloaded add-ons that default to being disabled on install.
The seen flag can be set to true through the API but cannot be reset to false
as that would allow add-ons to forcibly re-present themselves to the user when
disabled.
The opt-in UI sets the seen flag to true only when it has focus which fixes a
long-standing bug where if you accept the first add-on you see and restart the
other tabs might not show up.
The one slight downside of this approach is that it now requires loading the
full add-ons database on every startup in order to check the seen flag for all
installed add-ons. There are hacky ways we might get around this but they all
involve overloading prefs with even more object data. The good thing is that
we do the load and check asynchronously after most of startup is complete and
the UI is fully loaded so there shouldn't be any percieved impact to startup
time. I've run multiple talos runs to verify that none of the numbers appear to
regress.
Sometimes the Windows Media Foundation MFT video decoder reports that it will
provide memory for output video frames, and the decoder returns success, but it
doesn't output a valid video frame. So change our code to not assume that
output is always valid (to fix a null pointer dereference). We can't reproduce
this locally, so we don't know how to get a best behaviour here, so add
telemetry to figure out whether the decoder will right itself, or whether we
should just give up completely.
CLOSED TREE
Backed out changeset b76ab3324cd2 (bug 1214658)
Backed out changeset aee8341f15c7 (bug 1214658)
Backed out changeset 743d7567b280 (bug 1214658)
Now that the faster make backend is enabled by default avoiding
cross-jar.mn file conflicts, and now that individual files can't
overlap with wildcards in the same jar.mn files, which were two
main things that the "+" prefix was used for (apart from
cargo-culting), the "+" prefixes in the tree are not necessary
anymore.
