Bug 1894412 - When reading /etc/os-release, fall back to BUILD_ID when VERSION_ID is not set.  a=dmeehan

Arch Linux doesn't come with a VERSION_ID at all, but it has a BUILD_ID.
Semantically, falling back to BUILD_ID when VERSION_ID is not present
would seem fair play:

Per https://www.freedesktop.org/software/systemd/man/latest/os-release.html:

BUILD_ID=
    A string uniquely identifying the system image originally used as the
    installation base. In most cases, VERSION_ID or IMAGE_ID+IMAGE_VERSION
    are updated when the entire system image is replaced during an update.
    BUILD_ID may be used in distributions where the original installation
    image version is important: VERSION_ID would change during incremental
    system updates, but BUILD_ID would not. This field is optional.

Original Revision: https://phabricator.services.mozilla.com/D209089

Differential Revision: https://phabricator.services.mozilla.com/D209192

Original Revision: https://phabricator.services.mozilla.com/D203103

Differential Revision: https://phabricator.services.mozilla.com/D204101

Bug 1804978: Prevent release assert crashes due to a race when opening context menus on macOS. r=mstange, a=dsmith

Differential Revision: https://phabricator.services.mozilla.com/D198700

Original Revision: https://phabricator.services.mozilla.com/D195549

Differential Revision: https://phabricator.services.mozilla.com/D198576

Bug 1868737 - Allow minimal gfx features by default for uncertain configurations. r=jrmuizel,perftest-reviewers,kshampur a=RyanVM

Some features such as the GPU process (except on Android), backdrop
filter (because it always works with Software WebRender), ANGLE (because
it is generally good) and out of process WebGL (we generally want to
remote WebGL for sandboxing purposes) are special, and should not be
disabled simply because we are uncertain about our configuration. In
these situations, disable most features, but keep these enabled by
default.

Bug 1870159 - Use a different string for empty driver versions. r=aosmond,win-reviewers,mhowell a=RyanVM

This lets us distinguish parse failures from empty versions in
telemetry.

Backed out changeset 39193ec581e4 (bug 1833814)

Original Revision: https://phabricator.services.mozilla.com/D195549

Differential Revision: https://phabricator.services.mozilla.com/D198576

Original Revision: https://phabricator.services.mozilla.com/D198218

Differential Revision: https://phabricator.services.mozilla.com/D199684

Original Revision: https://phabricator.services.mozilla.com/D199035

Differential Revision: https://phabricator.services.mozilla.com/D199374

Original Revision: https://phabricator.services.mozilla.com/D195949

Differential Revision: https://phabricator.services.mozilla.com/D196685

Bug 1848628: Null-check swipe tracker before cleaning it up, in nsBaseWidget::SwipeFinished.  a=dmeehan

It seems unexpected that the swipe tracker would be non-null when a swipe
finishes, but there are several codepaths that can clear it, which might
conceivably fire while the SwipeFinished callback is in the queue to be
dispatched.

Note that before bug 1837226, SwipeFinished just nulled out the pointer, which
was harmless if it was already null.  My patch in bug 1837226 made us start
calling a method as well, and that created a new opportunity for a null-deref
crash here if the pointer happens to be null when we reach this function.

Original Revision: https://phabricator.services.mozilla.com/D186204

Differential Revision: https://phabricator.services.mozilla.com/D196360

Differential Revision: https://phabricator.services.mozilla.com/D195888

Original Revision: https://phabricator.services.mozilla.com/D192039

Differential Revision: https://phabricator.services.mozilla.com/D195330

Bug 1864118 - deny attempts to open a Windows file picker in headless mode. r=win-reviewers,gstoll,cmartin a=RyanVM

We don't necessarily even have access to a user-accessible desktop in
headless mode. Opening a file dialog isn't going to work out.

In practice, file-dialog invocations will typically be intercepted by
Puppeteer before they ever get here (see MockFilePicker.sys.mjs), but
that's configuration-dependent. Explicitly check whether we're in
headless mode before proceeding.

Differential Revision: https://phabricator.services.mozilla.com/D193332

Bug 1865302 [Linux] Don't resume compositor if we're missing mCompositorWidgetDelegate. r=emilio, a=RyanVM

We pause compositor for scale changes to avoid flickering during repaint.
If compositor is deleted during the pause, don't try to resume it.
Just flip it back to enabled and let SetCompositorWidgetDelegate() or map event to resume it.

Differential Revision: https://phabricator.services.mozilla.com/D194110

Differential Revision: https://phabricator.services.mozilla.com/D192316

Bug 1842170 - attempt to avoid nested event loops at inconvenient times r=win-reviewers,mhowell, a=dmeehan

If we enter `SpinEventLoopUntil` while certain Windows events are
waiting for resolution, we may enter an unusable state.

Since removing all `SpinEventLoopUntil` instances -- or even the one
causing this problem -- isn't really an option at present, kick the can
down the road by kicking the can down the road [sic].

Differential Revision: https://phabricator.services.mozilla.com/D185969

Bug 1851991: Do not try to raise the GPU process priority when it hasn't been initialized yet. r=jrmuizel, a=dmeehan

Differential Revision: https://phabricator.services.mozilla.com/D188275

Bug 1846205 - Use key state change to send activate/deactivate event when a modal window is opened; r=spohl,mac-reviewers, a=RyanVM

Original Revision: https://phabricator.services.mozilla.com/D188863

Differential Revision: https://phabricator.services.mozilla.com/D189231

Bug 1852801: Allow WinWindowOcclusionTracker members to fail initialization without crashing. r=rkraesig,win-reviewers a=RyanVM

This patch also expands the use of EnsureDisplayStatusObserver and
EnsureSessionChangeObserver, using them during the WinWindowOcclusionTracker
constructor, and also in WinWindowOcclusionTracker::Ensure. This gives another
opportunity for these observers to be created when
WinUtils::EnableWindowOcclusion is called.

Differential Revision: https://phabricator.services.mozilla.com/D188039

Differential Revision: https://phabricator.services.mozilla.com/D182817

Avoid (one instance of) loading `shell32.dll` in the content process by
delaying the resolution of special-directory names to paths until
they're passed up into the client process.

Differential Revision: https://phabricator.services.mozilla.com/D180988

Just like we rollup menus.

This is needed because tooltips otherwise get hidden on mousedown and
don't flush the view manager.

This matches the similar hunk for GTK in bug 1569439.

Differential Revision: https://phabricator.services.mozilla.com/D183489

Bug 1837226 part 3: Make nsBaseWidget::SwipeFinished destroy its SwipeTracker before clearing pointer. r=hiro, a=RyanVM

This new call should generally be a no-op, since we already un-register before
we get here, i.e. before we call SwipeFinished on the widget. This new call is
just to be extra-sure we're unregistered.  With this change, nsBaseWidget is
now consistent about calling Destroy before clearing its mSwipeTracker pointer.

Depends on D180240

Differential Revision: https://phabricator.services.mozilla.com/D180241

Bug 1837226 part 2: Upgrade some assertions to be release assertions in SwipeTracker.cpp. r=hiro, a=RyanVM

This patch just strengthens some invariants to be validated in release builds
as well.

Depends on D180239

Differential Revision: https://phabricator.services.mozilla.com/D180240

This patch doesn't change behavior. It just:
(a) avoids unnecessarily assigning the bool to false when it's already false.
(b) makes it easier to validate that we do truly only clear this bool when we
actually unregister.

Differential Revision: https://phabricator.services.mozilla.com/D180239

Original Revision: https://phabricator.services.mozilla.com/D182866

Differential Revision: https://phabricator.services.mozilla.com/D183447

which will allow a GtkIMContext to outlive the IMContextWrapper.

Original Revision: https://phabricator.services.mozilla.com/D182865

Differential Revision: https://phabricator.services.mozilla.com/D183446

Usually, this warning points at a problem (we're rendering a native
widget in light mode in a page where we should render it in dark mode).

However there are cases where we do this legitimately, for example for
the -moz-window-titlebar appearance. We render the light titlebar behind
the tabs to be able to render shadows appropriately.

We could probably only warn in some cases but honestly I don't think
that is particularly appealing, so let's remove it.

Differential Revision: https://phabricator.services.mozilla.com/D180961

We classify anything with 'mesa/vmgfx' as a Virtual Machine driver and
block it for Linux.

Differential Revision: https://phabricator.services.mozilla.com/D179864

Bug 1836021 [Linux] Probe VA-API devices if HW acceleration is force enabled (beta) r=emilio, a=dmeehan

Differential Revision: https://phabricator.services.mozilla.com/D181450

Bug 1832306 - Make `BrowserParent` stop handling access keys with delayed events r=smaug,NeilDeakin, a=dmeehan

`EventStateManager::WalkESMTreeToHandleAccessKey()` requests all `BrowserParent`
instances to handle access key in content processes:
https://searchfox.org/mozilla-central/rev/a4fd6daad3a4123d995478467c1274653b283801/dom/events/EventStateManager.cpp#1379,1398,1410-1411

Then, content processes will reply if no element matches with the access key:
https://searchfox.org/mozilla-central/rev/8e1b221afcdae76284b1439c547b032d1f84d236/dom/ipc/BrowserChild.cpp#2304-2305,2310

Finally, the parent process handles the keypress event:
https://searchfox.org/mozilla-central/rev/8e1b221afcdae76284b1439c547b032d1f84d236/dom/ipc/BrowserParent.cpp#2710-2712,2720,2725

However, this is odd because if multiple remote processes calls
`BrowserParent::RecvAccessKeyNotHandled()`, the parent process will handle
same `keypress` event multiple times.

The approach of this patch is, `BrowserParent` should store main data of
sending `eKeyPress` event, and `RecvAccessKeyNotHandled()` handles only if
the coming event matches with the stored one and clear the data to avoid
handling multiple times.

Even with this approach, we cannot avoid one `eKeyPress` event handled in
multiple content processes, or in both the main process and a content process.

Differential Revision: https://phabricator.services.mozilla.com/D179172

Differential Revision: https://phabricator.services.mozilla.com/D179909

Backed out changeset 7bc8c25b2935 (bug 1833244)
Backed out changeset 4576af83a4ec (bug 1833244)
Backed out changeset 90a5bbba7b9c (bug 1833244)

OS print drivers/devices know nothing about page dimensions unless we tell
them. Previously, the physical page dimensions (including orientation) have
always been the same, so communicating their dimensions once at the start of
a print has been enough. In preparation for supporting different "physical"
page dimensions (in the immediate future only different page orientations) when
we save to PDF, we need to have the infrastructure to pass dimensions through
on a page-by-page basis. This patch adds that.

None of the PrintTarget subclasses do anything with this extra information yet,
but in a follow-up patch PrintTargetPDF will use this information to create
PDFs with mixed page orientations.

Differential Revision: https://phabricator.services.mozilla.com/D179423

Differential Revision: https://phabricator.services.mozilla.com/D178745

Differential Revision: https://phabricator.services.mozilla.com/D178745

Calling it in destructor doesn't work as expected at all, since it's a virtual
function. Furthermore, it doesn't make sense to clear clipboard data every time
Firefox is closed.

Differential Revision: https://phabricator.services.mozilla.com/D178697