A past refactoring resulted in the functionality still working as intended - no
more than 8 topics being selectable at a time but when a topic would be
automatically deselected this would not show - that topic would still be
displayed as selected.
Moving the implementation to a new `FilterChip` Compose api fixes the UI issue
and also allows for more idiomatic code and fixes a previously disabled UI test
Change IntentReceiverActivity so that if the incoming intent has the private_browsing_mode extra set to true, it overrides the openLinksInAPrivateTab setting. This allows external apps to set this flag for sites they want opened in a private app explicitly.
External apps cannot force the link to open in a non-private tab if openLinksInAPrivateTab is enabled, in that case the extra will be ignored.
This is similar to an old fennec feature ( https://bugzilla.mozilla.org/show_bug.cgi?id=1347583 ), however I used the "private_browsing_mode" extra name since it already appears in the code, instead of the "private_tab" extra that fennec used.
Bugzilla bug is 1807531, GitHub bug is #26158
Restore showing a different description of the Tracking Protection feature in
application's onboarding if the Total Cookie Protection feature is not yet
public.
The new description mentioning Total Cookie Protection will only be shown if
the Total Cookie Protection CFR is to also be shown.
While debugging a UI test, we found that the messaging feature was being
queried during the storage initialization and acting on the cached value
alone. This could lead us to no longer receiving new messages during the
app lifetime.
For the unit tests, we switched from mocking the entire feature to
mocking just the `FeaturesInterface` as the test was providing
false-positive results. It's better to create a real feature in any case
for the other testing needs.
Co-authored-by: Benjamin Forehand Jr <bennyjr169@gmail.com>
