QuotaManager::CollectPendingOriginsForListing is a public template function so
it shouldn't be implemented in a cpp file.
(needed for moving operations outside ActorsParent.cpp)
Differential Revision: https://phabricator.services.mozilla.com/D181478
In python 3.11 (maybe also 3.10, I haven't tested that version ; 3.9 was
definitely different), by the time the context manager comes back in our
assertRaisesFromLine, the traceback is not available anymore (or yet,
I'm not entirely sure which way it does) to inspect and check the line
numbers we want to check.
And while assertRaises exposes the thrown exception in its `exception`
attribute, it also resets the traceback associated with it, so we can't
find it there either.
So instead, we implement our own context manager for
assertRaisesFromLine such that we can access that traceback.
Differential Revision: https://phabricator.services.mozilla.com/D181425
Python 3.10 added some more arguments to the CodeTypes constructor. It
also changed co_lnotab to co_linetables.
We were using co_lnotab to simulate a function with a def at a specific
line and a raise at a specific other line. I'm not sure how I ended up
with this particular requirement (this may have been related to python 2
still being used back then), but as of now, it doesn't seem we need the
def to be at a specific location, so we can avoid needing to generate
a co_linetables/co_lnotab, relying instead on the raise expression being
on the co_firstlineno+1 in the thrower function.
As for the extra arguments, it turns out python 3.8 also introduced a
CodeType.replace method that can be used to derive a CodeType object
from another, which is certainly simpler than calling its construtor
with the right set of arguments.
Differential Revision: https://phabricator.services.mozilla.com/D181424
The only tasks still using it are those doing PGO (profile use only) and
the builds that unify x64 and arm64 mac builds.
Differential Revision: https://phabricator.services.mozilla.com/D181728
be -> eaf273ac6eb746c800fc12c3bfcdcdb48c9766e3
cs -> 8e46be4f834f481882f0561c1b7465d9dda7344f
da -> f7455b2f38727cfa3d4b5472b3f93ba733fac57b
uk -> 3943ed227a0644977c9b9257ae7f3bffd778f4c8
This adds a `quickSuggestScoreMap` Nimbus variable that lets experiments
override suggestion scores. It maps from telemetry types to score values. For
example:
```
"quickSuggestScoreMap": {
"amo": 0.25,
"adm_sponsored": 0.3
}
```
In this example, addon suggestions will always have a score of 0.25, and
sponsored suggestions will always have a score of 0.3. Of course, different
branches within an experiment and different experiments can set different
scores.
While working on this, I saw we have a bug when we try to look up the
`BaseFeature` for a result. To do the lookup, we look up the result's
`telemetryType` in `FEATURE_NAMES_BY_TELEMETRY_TYPE`. That's a problem for `adm`
suggestions because the `telemetryType` will be either `adm_sponsored` or
`adm_nonsponsored`, but neither of those is present in
`FEATURE_NAMES_BY_TELEMETRY_TYPE` -- only `adm` is.
To fix it, I added back the `provider` property to result payloads that I
previously removed, and I added `BaseFeature.merinoProvider` so each feature can
specify its Merino provider. Then, `QuickSuggest` can build a map from Merino
provider names to features, allowing us to look up features without needing to
hardcode something like `FEATURE_NAMES_BY_TELEMETRY_TYPE` or
`FEATURE_NAMES_BY_MERINO_PROVIDER`.
Since I added back the `provider` property, I had to update a lot of tests. (As
a follow up, it would be nice to centralize the creation of expected result
objects in the test helper.)
I also added `BaseFeature.getSuggestionTelemetryType()` to help implement the
score map and to better formalize the idea that telemetry types are an important
property that all quick suggest results should include.
Differential Revision: https://phabricator.services.mozilla.com/D181709
Originally the test tried to scroll up, thus the content didn't scroll at all.
Now with scrolling down touch events, the content scrolls down even if the
long-tap event was preventDefaulted.
Depends on D176480
Differential Revision: https://phabricator.services.mozilla.com/D176481
This change includes three things;
1) Keep two different touch blocks alive during handling a long-tap event,
one is for the long-tap, the other one is the original block started with
touchstart.
2) Wait a content response again once after a long-tap event was processed
3) Unconditionally invoke ContentReceivedInputBlockCallback from APZEventState
for touchmove events so that it will properly route to APZ even if a content
response for the touchstart has already delivered to APZ.
With these now content responses for `contextmenu` events are handled by the
long-tap block, content responses for touch events are handled by the original
touch block respectively. As a result, `DoLongPressPreventDefaultTest` in
TestGestureDetector.cpp starts processing touch events in APZ thus we observe
a RequestContentRepaint call there, the test content isn't scrolled though. It
will change in the next commit.
Depends on D176479
Differential Revision: https://phabricator.services.mozilla.com/D176480
Before this change pointercancel events were fired only if
`mPendingTouchPreventedResponse` is true which means the events are not fired
after the flag was set to false via a `SendPendingTouchPreventedResponse(false)`
call in APZEventState::ProcessLongTap().
Depends on D176478
Differential Revision: https://phabricator.services.mozilla.com/D176479
`setContentResponse` was set to `true` in the `if (isTouchPrevented)` branch in
`case eTouchStart`, thus it's impossible we meet
(`setContentResponse && !touchPrevented`) condition.
Depends on D176477
Differential Revision: https://phabricator.services.mozilla.com/D176478
In a subsequent change, we will re-use this test code for testing a similar case
where we don't `preventDefault()` in the contextmenu event handler.
Depends on D176476
Differential Revision: https://phabricator.services.mozilla.com/D176477