Previously, the following scenario was possible:
1. aria-activedescendant is used on a menupopup to set a11y focus. When the event is processed, FocusManager::mLastFocus gets set accordingly.
2. aria-activedescendant on the menupopup is changed, so a focus event gets queued.
3. Before that focus event can be processed, the Accessible in (1) gets unbound from the a11y tree.
4. DocAccessible::UnbindFromDocument checks whether the Accessible is the last focus. As per (1), it is.
5. It then tells FocusManager to reset the active item, causing it to throw away the active item set in (2) and fire focus on the DOM focus (which is not the menupopup).
This breaks the new select dropdown implementation.
To fix this, we now set mLastFocus in DispatchFocusEvent (when the event is queued) instead of ProcessFocusEvent.
This way, we don't override a pending new focus change unintentionally.
Differential Revision: https://phabricator.services.mozilla.com/D65706
--HG--
extra : moz-landing-system : lando
This patch cleans up wasm compiler selection and a few related things
with as few semantic changes as possible. The intent is to centralize
compiler availability computation so that all parts of the system stay
in sync and it is easy to change compiler selection policy.
First, we introduce new predicates <Compiler>Available(cx) to test for
the actual availability of a compiler. These predicates take into
account whether a compiler is compiled into the executable, whether it
supports the hardware, whether it is (currently) selected by
options/switches, and whether it can be used as a result of the
runtime environment (for example, Ion and Cranelift are not available
if the debugger is observing the page or if the GC feature is enabled;
Cranelift is not available if shared memory and atomics are enabled).
We switch to using these predicates almost everywhere that used
<Compiler>CanCompile() or cx->options().wasm<Compiler>(), since those
don't tell the full story.
Second, we implement a priority order of the optimizing compilers and
make it easy to change this order (see comments in code). At the
moment, Cranelift is prioritized over Ion since Ion is enabled by
default and Cranelift is not; thus the desire of somebody flipping the
pref for Cranelift is to deselect Ion. The priority order may change
in the future or may become platform-dependent. The default compiler
selection in both browser and shell remains Baseline+Ion.
Third, we rename HasCompilerSupport() as HasPlatformSupport(), since
the predicate does not test whether compilers are available, only
whether they are present in the executable and support the hardware.
And to make that more sensible, <Compiler>CanCompile() is renamed
as <Compiler>PlatformSupport().
Fourth, we remove some redundant testing predicates (we don't need
both wasmDebugSupport and wasmDebuggingIsSupported, nor do we need
wasmUsesCranelift because wasmCompileMode is more reliable).
Fifth, we introduce a few new test cases that try to ensure that
compiler selection works as it should. These are white-box and may
need to change if the compiler priority order changes.
Sixth, we rename the internal wasm::Has<Feature>Support() predicates
as wasm::<Feature>Available(), since they all actually test for
compiler availability.
Differential Revision: https://phabricator.services.mozilla.com/D64946
--HG--
extra : moz-landing-system : lando
This patch enables the two sides of multiple-value calls in Ion:
* Calls from Ion to functions that return multiple values will pass a
pointer to a stack result area
* Compiling a function that returns multiple values with Ion will write
the values appropriately. There's a new MWasmStoreStackResult for
non-ref results; ref results use an MWasmDerivedPointer and
MWasmStoreRef.
The patch is otherwise untested but as multiple-value calls are still
gated by wasm::MaxFuncResults which is still 1, there's no risk to
browser users. Tests to follow.
Differential Revision: https://phabricator.services.mozilla.com/D64965
--HG--
extra : moz-landing-system : lando
So when I simply set the property on the window and flushed the display, I didn't
manage to get the desired effect.
Then I found this 'gxtuner' project that sends an event, which is correctly
picked up by Gnome and hopefully others.
Differential Revision: https://phabricator.services.mozilla.com/D65650
--HG--
extra : moz-landing-system : lando
Adding a repro-case reftest that asks for a 19996x5000 RenderTask (at
-p1), then fix it in analogy with the clamping to reasonable values that
happens for `NormalBorder`.
Differential Revision: https://phabricator.services.mozilla.com/D65660
--HG--
extra : moz-landing-system : lando
This patch ensures that the PDF viewer UI elements won't be zoomed in/out, on either initial loading or when resetting the zoom level, when a non-standard global default zoom level is set. Also hides the zoom indicator, in the Address Bar, in this case to avoid inconsistent state when the PDF viewer is used.
Differential Revision: https://phabricator.services.mozilla.com/D64819
--HG--
extra : moz-landing-system : lando
See the comment for the sadness. Otherwise there was quite a lot of fuzz to
annotate.
Differential Revision: https://phabricator.services.mozilla.com/D65666
--HG--
extra : moz-landing-system : lando
Define and use fuzzing-builds optimization strategy that allows either
skip-unless-schedules or seta strategies.
Differential Revision: https://phabricator.services.mozilla.com/D64628
--HG--
extra : moz-landing-system : lando
The one message it responds to is never sent since bug 1574480 removed it, and the one event it listens to only ends up adding the window to a manifest set which is no longer used for anything since bug 1579444 removed it, r=johannh
Differential Revision: https://phabricator.services.mozilla.com/D65322
--HG--
extra : moz-landing-system : lando
Changes:
Remove all tests other than `reftests`, `crashtests` and `mochitest-media` for windows10-aarch64.
Important changes are in `taskcluster/ci/test/test-platforms.yml` and `taskcluster/ci/test/test-sets.yml`.
I've gone ahead and removed the windows10-aarch64 specific entries in the YAML files as well.
Differential Revision: https://phabricator.services.mozilla.com/D65654
--HG--
extra : moz-landing-system : lando
Changes:
Pin the source docker image to a specific tag from canonical.
Remove unneeded packages that are either installed as part of the setup, or come preinstalled.
Silence the `dbus` startup message by redirecting the output to `2&>1`.
Remove unnecessary `locale-gen` call at the end of setup.
Differential Revision: https://phabricator.services.mozilla.com/D65434
--HG--
extra : moz-landing-system : lando
We don't ship openh264 builds on android, so there is no need
to build them in automation.
Differential Revision: https://phabricator.services.mozilla.com/D65669
--HG--
extra : moz-landing-system : lando
These jobs only use the workspace for obj directories, have some some logic to
cleanup the directory at the beginning of the run, so there is no reason to
cache the directory.
This also removes the now-unused common code for creating a workspace cache directory.
Differential Revision: https://phabricator.services.mozilla.com/D62486
--HG--
extra : moz-landing-system : lando
This is instead of extracting them in the gecko source directory, where they
will get deleted by the next task anyway.
Differential Revision: https://phabricator.services.mozilla.com/D65628
--HG--
extra : moz-landing-system : lando
Since the workspace is no longer cached, but needs to be a volume for
performance reasons, add a check to ensure that is the case.
Differential Revision: https://phabricator.services.mozilla.com/D62484
--HG--
extra : moz-landing-system : lando
Since mozharness tasks are no longer caching the workspace directory, we don't
need a key for different tasks.
Differential Revision: https://phabricator.services.mozilla.com/D62483
--HG--
extra : moz-landing-system : lando
This moves the object directory and source directories around in all mozharness
jobs, to allow enabling caching on windows builders.
This makes a number of changes that all need to land at once:
- Move the source checkout for the workspace cache mount, to the checkouts
cache mount.
- Makes the object directoy from underneath the source directory, to directly
in the work directory (which is still under `workspace`).
- Sets the object directory to `obj-build` instead of `obj-firefox`.
- Stops caching the workspace directory (it is still a volume in docker workers,
so writes perform well; a followup revision add some checks around this).
- Removes one level of directory in the mozharness workdir (things were under
`workspace/build`, but are now just under `workspace/`.
- Adjust paths in environment variables and artifact specifications to match
the above changes.
Differential Revision: https://phabricator.services.mozilla.com/D62482
--HG--
extra : moz-landing-system : lando
Masayuki Nakano
Tim Nguyen
Sebastian Hengst
shindli
James Teh
Simon Giesecke
Lars T Hansen
Mirko Brodesser
Andy Wingo
Martin Stransky
Andreea Pavel
Benjamin Bouvier
Mike de Boer
Mihai Alexandru Michis
Bert Peers
Jonas Jenwald
Emilio Cobos Álvarez
Bob Clary
Neil Deakin
Edwin Takahashi
Jeff Walden
Julian Descottes
Tom Prince