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

Bug 1543990 - Simplify nsISpeculativeConnect API, r=necko-reviewers,geckoview-reviewers,search-reviewers,valentin,m_kato

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

Since the headless work (bug 1129492 and co) we realistically have no
way of rendering native scrollbars in any meaningful way. Remove dead
code that used to support using a different GTK theme on content.

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

This also makes SelectionCache type supports clipboard owner.

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

Bug 1812078 - Part 1: Have separated clipboard caches for each clipbaord type to track clipboard owner; r=mstange

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

It's not clear to me why specializing nsCOMPtr<nsISupports> is
particularly useful, and this removes a lot of code, bringing us closer
to unifying nsCOMPtr and RefPtr.

The changes in other places are needed because we used to allow
nsCOMPtr<nsISupports> to implicitly coerce to nsISupports even for
rvalue references.

     0:47.88 /home/emilio/src/moz/gecko-4/netwerk/protocol/http/nsHttpActivityDistributor.cpp:121:11: error: conversion function from 'nsCOMPtr<nsISupports>' to 'nsISupports *' invokes a deleted function
     0:47.88           nsCOMPtr<nsISupports>(do_QueryObject(channel)), aActivityType,
     0:47.88           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     0:47.88 /home/emilio/src/moz/gecko-4/obj-debug/dist/include/nsCOMPtr.h:764:3: note: 'operator nsISupports *' has been explicitly marked deleted here
     0:47.88   operator T*() const&& = delete;
     0:47.88   ^
     0:47.88 /home/emilio/src/moz/gecko-4/netwerk/protocol/http/nsHttpActivityDistributor.cpp:29:57: note: passing argument to parameter 'aHttpChannel' here
     0:47.88 nsHttpActivityDistributor::ObserveActivity(nsISupports* aHttpChannel,
     0:47.88                                                         ^

Which is not allowed for a good reason, generally.

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

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

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

Backed out changeset 9fce1abd1c50 (bug 1833244) for causing build bustages on nsDeviceContextAndroid.h. CLOSED TREE

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.

Depends on D179395

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

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

Add separate options to control whether we build VA-API and/or V4L2
hardware video decode.  These options default to enabled on the
platforms where these decoders are used.

The downstream MOZ_WAYLAND_USE_HWDECODE build option is used within the
FFmpeg platform and is only set when building against a supported
version of the FFmpeg libraries (i.e. not for ffmpeg57).

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

Bug 1834945 - Include chromium-config.mozbuild in widget/uikit, to get ipdl headers. r=firefox-build-system-reviewers,nalexander

Same as other widgets.

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

Bug 1704954 disabled DirectComposition for users with NVIDIA graphics
hardware and mixed monitor refresh rates on Windows 10 and 11, as a
mitigation for bug 1638709. However, that bug is almost -- perhaps
entirely -- unknown on Windows 11 (q.v. for details), and the fallback
path it uses has been shown to cause issues there (bug 1763981).

Restrict the mitigation to only occur on Windows 10, where bug 1638709
is exhibited, but where no issues with the fallback path are known.

This also effectively reverts bug 1816001, which it obviates.

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

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