This avoids starting autoscroll on SVG links, and on HTML links that
contain SVG, by sharing the code that browser's ClickHandlerChild uses
to detect links into BrowserUtils, and using that from AutoScrollChild
to determine if the click happened on top of a link. It also adds a
test so we avoid regressing this in future.
When running the test, I noticed an error from ClickHandlerParent
when the browser for which we receive a click has gone away, and
fixed it by adding a nullcheck and early return.
Differential Revision: https://phabricator.services.mozilla.com/D120024
They were made tier 3 in bug 1638607 because they were breaking
regularly. Back then, it was expected they would work better once we
switch to clang 12, which we have done, and the history of the
diffoscope tasks in the past couple months show they are not regularly
failing anymore.
Differential Revision: https://phabricator.services.mozilla.com/D120054
At the moment, lucetc is not useful by default, only when enabling wasm
sandboxed libraries manually, and in that case, configure knows to
bootstrap lucetc itself. Furthermore, lucetc is set to be replaced with
wasm2c, which is in-tree and doesn't require bootstrapping at all.
Differential Revision: https://phabricator.services.mozilla.com/D120051
It turns out calling gdk_display_close gets us a rematch of bug 1626536,
so remove the call that was added in bug 1718131, and adjust valgrind
suppressions accordingly.
Differential Revision: https://phabricator.services.mozilla.com/D120037
Since wasi build has been green for three weeks and since developers don't
want to break this build we give them
tier 2 to make it more visible.
Differential Revision: https://phabricator.services.mozilla.com/D119960
h2 proxy bug 1563538 added a temporary "network.http.spdy.bug1563538" pref in case its tunnel stream fix needed to be disabled quickly. That was almost two years ago (Firefox 68) and we haven't needed to disable this pref yet, so we can probably remove this pref and the old code paths now.
Differential Revision: https://phabricator.services.mozilla.com/D119942
When the document is hidden from view, silently drop position updates on the floor. This aligns, more or less, with Chrome and Safari.
The situation with "not fully active" is a bit more quirky, because non-fully active documents are generally hidden (e.g., `remove()`ing and iframe).
Regardless, I think this gives us the desired behavior and covers the main privacy case: background tabs should not receive position updates.
Differential Revision: https://phabricator.services.mozilla.com/D109279
The very first time an Android AVD starts it runs some one time jobs to
properly set up the AVD.
To avoid running the setup every time we run tests in automation, we can boot
the AVD before packaging it so that the testing jobs can use a "prewarmed" AVD
instead.
Differential Revision: https://phabricator.services.mozilla.com/D119225
Tooltool images are hard to update because we don't provide a script to
generate the image and documentation is often inaccurate.
This patch makes it so we generate the AVD in the android-sdk TL job instead.
Differential Revision: https://phabricator.services.mozilla.com/D119221
The ARM emulator images have very poor support and haven't been updated for a
long time.
Normally x86_64 images need KVM acceleration which is not available on build
machines (see Bug 1545497). We can work around this by starting the emulator
with the command line |--no-accel|.
Differential Revision: https://phabricator.services.mozilla.com/D119223
7.3.0-1 was used because it was the last 7.x that provided the libstdc++6
package. Unfortunately, once libstdc++ is removed from the clang
toolchain, which makes the one from the sysroot used instead, it causes
an ASan issue which goes away when using a more recent version (which the
libstdc++ from clang was: it was 7.5).
So we take the last 7.x that exists, and tweak it so that it generates
the necessary libstdc++6 package.
Differential Revision: https://phabricator.services.mozilla.com/D120012
We use the process handle returned from `CreateProcess` to derive
another handle with more permissions, but the original handle is never
closed. This bug appears to be fairly old: it existed before this code
was converted to use MozPromise.
Currently we provide the original handle to external consumers of the
launch promise; this patch resolves the promise with the privileged
handle instead and closes the original one. (One consumer uses the
handle only to obtain the pid, and the rest don't use it at all, so this
shouldn't change anything.)
As a related cleanup, `ProcessLaunchPromise` is now exclusive (because
it's resolved with resources which are consumed) and no longer declared
in the header file (because it's used only internally).
Differential Revision: https://phabricator.services.mozilla.com/D119820
Henrik Skupin
Gijs Kruitbosch
Sebastian Zartner
Marian-Vasile Laza
Edgar Chen
Sebastian Hengst
Jonathan Kew
Miko Mynttinen
Paul Adenot
Jon Coppeard
Emilio Cobos Álvarez
Mike Hommey
Dmitry Bezhetskov
Amir M. Saeid
Chris Peterson
shravanrn@gmail.com
Sandor Molnar
Marcos Cáceres
Cosmin Sabou
Geoff Lankow
Agi Sferro
Agi Sferro
Jed Davis
Florian Quèze