Use lld to build them (as well as aarch64 linux compiler-rt).
While here, remove redundant CMAKE_SHARED_LINKER_FLAGS in the Android case.
Differential Revision: https://phabricator.services.mozilla.com/D138746
This simplifies the setup for cross clang repacks.
Also use `ninja install` to get all the relevant things in the artifact.
Differential Revision: https://phabricator.services.mozilla.com/D138745
Bug 1752977 attempted to do that, but that part had to be backed out as
a fixup because it broke LTO support for the linker.
To make it work, cctools needs to link against clang's libLTO, which
requires libLTO to be built with the toolchain sysroot. But system GCC
doesn't support that in a nice way, so we switch to system clang. We
explicitly don't use /usr/bin/clang++ because that would use the system
libstdc++ headers instead of the ones from the sysroot, while using
/usr/lib/llvm-11/bin/clang++ uses the ones from the sysroot.
We keep building clang 5.0 with gcc, though, because that one fails to
build with clang 11.
Differential Revision: https://phabricator.services.mozilla.com/D138712
With enabling apz.allow_zooming, both test and reference contents are scaled
down on mobile environments but the scaled size is different because the content
width is different.
Differential Revision: https://phabricator.services.mozilla.com/D138874
We already call MaybeQueueCacheUpdateForStyleChanges from DidSetComputedStyle for reconstructed frames.
However, at that point, nsIContent::GetPrimaryFrame (and thus LocalAccessible::GetFrame) returns null, which means we're unable to check for style changes.
Instead, we now handle style changes for reconstructed frames in PruneOrInsertSubtree, at which point the frame is definitely available.
Differential Revision: https://phabricator.services.mozilla.com/D138627
Now that the main cause of broken stacks (LoaderObserver) has been removed, we reinstate the path to this assertion, which should trigger much less or not at all.
Differential Revision: https://phabricator.services.mozilla.com/D138241
When a linkable accessible has an action because of an ancestor, don't
cache it directly, but instead walk up in the parent process to find it.
Depends on D137200
Differential Revision: https://phabricator.services.mozilla.com/D137201
nsIX509CertValidity had a handful of APIs that would return formatted time
values. Some of these APIs were unused, and the rest were prone to error due to
platform differences. This patch simplifies this interface by removing those
APIs and having callers perform their own formatting using the remaining APIs
that return PRTime values.
Differential Revision: https://phabricator.services.mozilla.com/D138363
This basically undoes bug 1246346. The current behavior is pretty bizarre,
the screenX origin / position doesn't match the mouse event coordinates,
because on windows we return device pixels rather than CSS pixels for the
window coordinates.
This makes behavior consistent with how other browsers report these coordinates
at least on Windows in non-mixed DPI mode, and I think is fine.
In mixed DPI mode, there might indeed be overlapping coordinates, but again I
think that's fine, because the CSS coordinate space of the different monitors
is different. You need to multiply by the devicePixelRatio if you want
coordinates not to overlap.
Depends on D138039
Differential Revision: https://phabricator.services.mozilla.com/D138130
Device pixels and desktop pixels are not the same on macOS and Win7.
Expose the desktop-to-device scale to JS and use it appropriately.
Depends on D138038
Differential Revision: https://phabricator.services.mozilla.com/D138039
Android has no full-page zoom, so we are not meaningfully changing behavior.
However, these values are exposed to the GeckoView JS api, surprisingly, yet
viewport scaling and so on can change the CSS to device pixel ratio...
Shouldn't we expose device pixels there instead? Or do the api consumers assume
that those CSS pixels are scaled to the device scale factor somehow (and that's
not working)?
Depends on D138037
Differential Revision: https://phabricator.services.mozilla.com/D138038
If the page is zoomed, its devicePixelRatio will differ from the browser
chrome's. Account for this by converting to device pixels before starting to
scroll.
Depends on D138036
Differential Revision: https://phabricator.services.mozilla.com/D138037
If the page is zoomed, its devicePixelRatio will differ from the browser
chrome's. Account for this by converting to device pixels before starting to
scroll.
Depends on D138035
Differential Revision: https://phabricator.services.mozilla.com/D138036
We report window.screen coordinates in CSS space, so it makes sense to do
the same for screen-relative offsets. This requires some front-end fixes
incoming in following patches.
Differential Revision: https://phabricator.services.mozilla.com/D138035
We switch the open state storage to the element rather than the frame,
to be able to preserve it across reframes.
The code is loosely based on nsHideViewer in nsSubDocument.cpp, but it's
simpler because we don't need to do restoration shenanigans.
Differential Revision: https://phabricator.services.mozilla.com/D138689
If the android system kills the GPU process then ChildCrashHandler.jsm
gets invoked but an empty dump ID. Currently we generate a crash
report anyway, which is resulting in lots of "EMPTY: no crashing
thread identified; ERROR_NO_MINIDUMP_HEADER" crashes.
Instead, we should return early before starting the crash reporter if
the dump ID is empty. We already do this for content processes, so
this patch makes us do so for every type of process.
Differential Revision: https://phabricator.services.mozilla.com/D138766
Make the ScreenOrientation part of the screen struct, as it should. Stop
using HAL to propagate just screen orientation updates, use the more
general screen manager.
Instead of HAL observers, add a simple observer service notification,
and clean a bunch of the code.
This will simplify bug 1754802 a bit, and is generally simpler.
Shouldn't change behavior. I've tested the events and some common
orientation locking use cases like Youtube, and they behave the same.
Differential Revision: https://phabricator.services.mozilla.com/D138477