The initialization costs of the TabList constructors is very small compared to
the cost of actually calling _populate, so instead of calling init() from an
idle task, we can just wait until the view actually needs to be shown.
Differential Revision: https://phabricator.services.mozilla.com/D73946
This patch will do :
- replace the old pref with the new pref
The advantage of doing so :
- to ensure those tests can still use the correct blocking autoplay policy
Differential Revision: https://phabricator.services.mozilla.com/D73973
This patch will do :
- set the value of the new pref based on the value of the old pref
The advantage of doing so :
- ensure that the value of the pref can be transformed correctly
Differential Revision: https://phabricator.services.mozilla.com/D73972
This patch will do :
- rename the old pref `media.autoplay.enabled.user-gestures-needed` to the new pref `media.autoplay.blocking_policy`
- modify the value of the pref to `int` in order to introduce new policy
- implement new policy in `AutoplayPoliocy`
The advantage of doing so :
- rename the pref to explicitly indicate that it's related the block policy we use
- use the transient user gesture activation as a new policy to replace the old one using the user input, which doesn't work on the async handler
More details :
The old `click-to-play` policy we use is using the user input to determine if the play invocation is called by users or by scripts. But `UserActivation::IsHandlingUserInput()` is buggy which would fail when you call `video.play()` inside an async event handler. So we would like to replace it with the new transient user activation, which would treat the action as an user input if the action is performed within a certain period of time after a user interacts (eg. click) with the page.
[1] https://html.spec.whatwg.org/multipage/interaction.html#transient-activation
Differential Revision: https://phabricator.services.mozilla.com/D73971
This patch will do :
- replace the old pref with the new pref
The advantage of doing so :
- to ensure those tests can still use the correct blocking autoplay policy
Differential Revision: https://phabricator.services.mozilla.com/D73973
This patch will do :
- set the value of the new pref based on the value of the old pref
The advantage of doing so :
- ensure that the value of the pref can be transformed correctly
Differential Revision: https://phabricator.services.mozilla.com/D73972
This patch will do :
- rename the old pref `media.autoplay.enabled.user-gestures-needed` to the new pref `media.autoplay.blocking_policy`
- modify the value of the pref to `int` in order to introduce new policy
- implement new policy in `AutoplayPoliocy`
The advantage of doing so :
- rename the pref to explicitly indicate that it's related the block policy we use
- use the transient user gesture activation as a new policy to replace the old one using the user input, which doesn't work on the async handler
More details :
The old `click-to-play` policy we use is using the user input to determine if the play invocation is called by users or by scripts. But `UserActivation::IsHandlingUserInput()` is buggy which would fail when you call `video.play()` inside an async event handler. So we would like to replace it with the new transient user activation, which would treat the action as an user input if the action is performed within a certain period of time after a user interacts (eg. click) with the page.
[1] https://html.spec.whatwg.org/multipage/interaction.html#transient-activation
Differential Revision: https://phabricator.services.mozilla.com/D73971
In RFP mode, canvas image extraction leads to an all-white image, replace that
with a random (sample 32 bytes of randomness and fill the buffer with that)
'poison pill'. This helps defeat naive fingerprinters by producing a random
image on every try. This feature is toggled using a new, default on, pref
`privacy.resistFingerprinting.randomDataOnCanvasExtract`.
Updated `browser_canvas_fingerprinting_resistance.js` to test this new feature
as well.
Updates and replaces D66308.
Differential Revision: https://phabricator.services.mozilla.com/D72716
Fix up the browser_tab_label_during_restore.js test to wait for the right number of tab title changes, since the timing of the tab title updating has now changed.
Differential Revision: https://phabricator.services.mozilla.com/D72562
The tracker base class currently does two things: bump the score in
response to observer notifications, and store a list of changed IDs.
The bookmarks, form autofill, and now bridged trackers need to hack
around this to opt out of persistence, since they handle change
tracking in the storage layer.
This commit keeps the score logic in `Tracker`, but moves all the
persistence code into an intermediate `LegacyTracker` class, and
changes all engines that need persistence to inherit from it.
`ignoreAll` is more interesting. We want new-style stores to emit
observer notifications with change sources, so that the tracker knows
to ignore changes made by Sync. Ignoring all observer notifications
during a sync is a blunter version of this. But, not every new store
supports change sources, so we reimplement `ignoreAll` manually for
ones that don't.
Differential Revision: https://phabricator.services.mozilla.com/D74374
This patch does not add support to SearchSuggestionsController's consumers. Do not use this patch without the subsequent Part 3 patch as well.
Differential Revision: https://phabricator.services.mozilla.com/D74118
Unify two separate codepaths that do conceptually identical things. That is,
instead of having the widget code directly dispatch wheel and pinch gesture
events to Gecko, allow APZ to do it as part of it's handling of pinch inputs
when zooming is disabled.
The main difference is that the WidgetSimpleGestureEvent delta values come out
different, because they are based on the macOS event's magnification value,
rather than the (now deprecated) deltaZ value. This is actually better since it
makes the values consistent across platforms and allows removal of some ifdefs.
Differential Revision: https://phabricator.services.mozilla.com/D74640
By returning false (or not adding results to `context.results`), the muxer
signals that it needs more results in order to decide how to sort them and to
sort them without flickering. After the providers manager calls each provider's
`startQuery`, it removes the provider from `context.activeProviders` and calls
`_notifyResultsFromProvider` one more time so that the muxer can resort if
necessary given the new `context.activeProviders`.
We can also be a little faster and more efficient by making only two passes over
the results, and by keeping a `context.heuristicResult` property that's updated
by the providers manager.
This also fixes a bug with the search suggestions provider, where it didn't
include a suggestion that matched the user's search string even if the heuristic
result was not a search result (e.g., if it's an autofill). That deduping logic
should be done in the muxer.
Finally this removes browser_restyleSearches.js since the muxer changes removed
part of the restyling functionality. I'll file a follow-up to remove other parts
of restyling.
Differential Revision: https://phabricator.services.mozilla.com/D74192