It looks like we had support for Android before but since the Bug 1835065, we
lost this feature. This is because it looks like we added some
`self.config["app"] == "firefox"` checks to profiler related code and firefox
for android has different app name (like "geckoview" or "fenix").
This patch brings back the android profiling by changing those if checks to
include the android firefox adds as well.
Differential Revision: https://phabricator.services.mozilla.com/D187666
Rewrite `test_autocomplete_autofill_related_realms_no_dupes.html` and introduce
* `setPreferencesForTask(...preferences)`
* `setStoredLoginsDuringTest(...loginInfos)`
* `setStoredLoginsDuringTask(...loginInfos)`
* `formAutofillResult(formId)`
which handles state cleanup between tests and tasks.
This includes a simplified version and implementation of Sergs work on a form
autofill listener (https://phabricator.services.mozilla.com/D167214) but based
on the task hook, and incorporating some learnings from
https://phabricator.services.mozilla.com/D185192
Differential Revision: https://phabricator.services.mozilla.com/D187435
Switch a sample test to use `storeLoginsDuringTask(...loginInfos)` and
`setContentForTask(html)`, which are powered by task cleanup fn.
Differential Revision: https://phabricator.services.mozilla.com/D187271
Helpers and tests can hook into the test task lifecycle to provide a code that
will be executed after the current task is finished
(`SimpleTest.registerCurrentTaskCleanupFunction`), or after each task
(`SimpleTest.registerTaskCleanupFunction`). In doing so, for example, state can
be cleaned up.
Differential Revision: https://phabricator.services.mozilla.com/D187211
This fixes a performance cliff in some cases where we'd attach a slower stub instead.
This could happen with spread calls for example.
Differential Revision: https://phabricator.services.mozilla.com/D187904
Bug 1596930 added support for detouring a pattern of code used by eScan
Internet Security Suite. The patch also added tests to make sure
that we correctly detour this pattern.
The pattern involves a PUSH instruction followed by a RET instruction.
This pattern is forbidden by Intel CET, which enforces at RET time that
we always return to an address that was pushed on the stack by a
prior CALL instruction. Executing the pattern thus crashes if Intel CET
is active.
If CET is active, we must thus skip the execution part of the test, or
the test crashes. We will still check that our detouring code
recognized the pattern and detoured it, but we will not run the detoured
pattern anymore under active Intel CET.
Differential Revision: https://phabricator.services.mozilla.com/D163468
Firefox versions >= 116 only support macOS >= 10.15. All the callers of these runtime version checks for macOS 10.12 - 10.15 have been removed so we can now remove these functions, too.
Differential Revision: https://phabricator.services.mozilla.com/D187868
This change adds the PHCManager class which observes a pref to control PHC.
The pref can be changed at runtime and will affect the parent and content
processes.
Differential Revision: https://phabricator.services.mozilla.com/D178754
We will need the snap area, (i.e. SnapTarget::mSnapArea) in SnapPosition to tell
whether the snap area is visible or not if we snap to a candidate snap position.
Though SnapPosition::mPosition is redundant, it's equivalent to either
SnapTarget::mSnapPoint.mX or SnapTarget::mSnapPoint.mY, if we omit it, we need
another variable representing the axis of SnapPosition.
Differential Revision: https://phabricator.services.mozilla.com/D184341
We could avoid adding the snap area into ScrollSnapRange if we added two
additional flags representing whether the snap area size is larger than the
snapport into SnapTarget and drop ScrollSnapRange entirely. But it would
be inefficient in most cases since such larger snap area cases are uncommon, we
will not find any larger snap areas while iterating over
ScrollSnapInfo::mSnapTargets.
Differential Revision: https://phabricator.services.mozilla.com/D184340
It's possible that multiple snap target elements are located at the same
position in one axis but at different position in the other axis. We need to
keep track of them respectively in each CandidateTracker.
Differential Revision: https://phabricator.services.mozilla.com/D184339
snap-to-combination-of-two-elements-2.tentative.html is a bit questionable,
thus it's tentative for now.
We fail the tentative test due to bug 1768393. Chrome also fails in a different
way. Chrome seems to filter out snap target elements initially if they are
outside of the scroll port and then determine the final snap position. Thus snap
positions defined by #right-bottom element in the test are ignored in the case
of the initial scroll position (0, 0).
Differential Revision: https://phabricator.services.mozilla.com/D184332
Previously, we cached when a UIA client was blocked or when there were no UIA clients.
However, we did not cache the result when a UIA client was present but *not* blocked.
This isn't normally a problem because a11y is normally instantiated in this case, which means we won't try to do any client detection again this session.
However, if a11y is force disabled via the pref, we still do detection, but we don't instantiate.
This meant that a UIA client which hammered us with queries would keep triggering the detection code, since we weren't caching the result.
That resulted in severe performance degradation for impacted users.
To fix this, cache the UIA detection result even if we do allow a11y instantiation.
Differential Revision: https://phabricator.services.mozilla.com/D187869
As of bug 1719535, libm is vendored, so we don't need to pull it out of
packed_simd anymore, and that was the last remaining difference between
upstream and our fork.
Differential Revision: https://phabricator.services.mozilla.com/D187413
