Our data indicates a few users of x86 system hit failure to load urlmon.dll
for unknown reasons. Since we don't always require urlmon.dll,
we delay-load it, which causes a crash if loading urlmon.dll fails.
A proposed fix is to dynamically load urlmon.dll on x86.
Differential Revision: https://phabricator.services.mozilla.com/D88534
This patch defines a new macro `MOZ_USE_LAUNCHER_ERROR` and keeps
the use of `LauncherError` behind `MOZ_USE_LAUNCHER_ERROR` instead of
`MOZILLA_INTERNAL_API` so that we can selectively use `LauncherError`
in locations where `MOZILLA_INTERNAL_API` is defined.
Differential Revision: https://phabricator.services.mozilla.com/D83638
WM_INITDIALOG is a special case for this hook. Returning TRUE tells it to set they keyboard focus.
In all other cases returning 0 from the hook invokes the standard behavior.
Differential Revision: https://phabricator.services.mozilla.com/D87870
Somewhere along the way, we fix the tests that are too fragile with respect to race conditions between processes to make them pass chaos mode testing.
Depends on D83623
Differential Revision: https://phabricator.services.mozilla.com/D83971
This retrieves the same settings from the printer as
InitPrintSettingsFromPrinter.
There is probably a lot of scope for de-duplication of code here, but I decided
to try and protect the old fallback paths.
Depends on D87125
Differential Revision: https://phabricator.services.mozilla.com/D87604
This patch adds a createDefaultSettings() method to nsIPrinter to
initialize a default print settings object specific to that printer.
It implements the functionality for Linux and macOS but adds only stubs
for Windows.
Differential Revision: https://phabricator.services.mozilla.com/D87125
This patch adds a createDefaultSettings() method to nsIPrinter to
initialize a default print settings object specific to that printer.
It implements the functionality for Linux and macOS but adds only stubs
for Windows.
Differential Revision: https://phabricator.services.mozilla.com/D87125
See bug for justification. This patch aims to display a blank window prior to
loading/prefetching xul.dll. It also has a placeholder for drawing a
skeleton UI into that window. Note that this is disabled by default based on
a registry value, as there are still kinks to work out (for instance, what
happens if we aren't actually going to display a window, because, say, Firefox
is already running.) This just gives a basic implementation to dogfood, and
facilitates distributing work across multiple contributors.
Onto the details. The patch achieves its goal by creating a window and
assigning its handle to a static variable, which will be consumed inside
nsWindow::Create by the first toplevel window we want to make. nsWindow::Create
will take ownership of the window handle, restyle it to its own liking, and
then proceed as if everything is normal and it had created the window itself.
Differential Revision: https://phabricator.services.mozilla.com/D86263
See bug 1648489 for why we need this.
If we don't send a pinch we don't want to update the last scale so that when we do send an event it incorporates the full scale change from the last time we sent an event.
Even if aScale != mLastScale in SendPinch the computed deltaY ( = 100 * (aScale-mLastScale) * widgetscale) can be 0 seemingly because of floating point weirdness I guess.
Depends on D86495
Differential Revision: https://phabricator.services.mozilla.com/D86496
Whole firefox only needs one wakelock instance, requesting more wakelock doesn't help anything. As those notification would be sent to chrome process as well, so we would only need one listener in chrome process to prevent requesting unnecessary wakelock.
Differential Revision: https://phabricator.services.mozilla.com/D85818
We do this analogously to how PanGestureInput does it except that the delta's that we compute mLineOrPageDeltaY from are computed by us instead of provided to us.
mLineOrPageDeltaY being non-zero is what EventStateManager::DispatchLegacyMouseScrollEvents uses to decide to send legacy mouse events, so we need to populate it to get those legacy events to send.
This fix is Windows only on purpose as pinches on macOS don't seem to send wheel events (Windows sends ctrl+wheel). When Linux gets implemented it will need to be determined what to do.
Differential Revision: https://phabricator.services.mozilla.com/D86495
The existing rollup-handling code in SendAnAPZEvent was mostly copied from
the DealWithPopups function, so this patch removes that duplication and reuses
the existing codepath. And it adds some extra checking for dmanip events that
mirrors the checking we do for other events, so that events that are targeted
inside the popup don't cause the popup to get rolled up.
Differential Revision: https://phabricator.services.mozilla.com/D86603
This allows us to reuse this function and the GetPopupsToRollup function when
an event point is different than what comes out of GetMessagePos.
For instance, the WM_POINTERDOWN code can now reuse this functions properly.
This fixes a latent bug where it was calling GetPopupsToRollup which was using
an possibly-incorrect point internally.
Differential Revision: https://phabricator.services.mozilla.com/D86754
GetProcInfo is designed to collect process & thread data while they're running,
which means that it needs to handle the case in which a thread shuts down while
we're looking at it.
By design, in case of failure, GetProcInfo return partial data in case of failure.
This patch ensures that we always either set the thread ID (which we use to display about:processes) correctly or remove
the thread entirely from the list.
Differential Revision: https://phabricator.services.mozilla.com/D86055
I intentionally removed the "move the default printer to the front" in
windows because that's not a guarantee that we provide in CUPS, but lmk
if you want it back.
I have zero idea about why the GlobalPrinters code was so ridiculously
complex.
Depends on D86396
Differential Revision: https://phabricator.services.mozilla.com/D86397
The resource file is always generated so being able to configure its name
is not useful. On the other hand, the way things are currently implemented,
the lack of RESFILE also makes RCFILE ignored, which we fix at the same
time.
And remove a spurious RESFILE in widget/windows/moz.build, where no binary
is produced, which means RESFILE had no meaning.
Differential Revision: https://phabricator.services.mozilla.com/D86154
The resource file is always generated so being able to configure its name
is not useful. On the other hand, the way things are currently implemented,
the lack of RESFILE also makes RCFILE ignored, which we fix at the same
time.
And remove a spurious RESFILE in widget/windows/moz.build, where no binary
is produced, which means RESFILE had no meaning.
Differential Revision: https://phabricator.services.mozilla.com/D86154
Narcis Beleuzu
David Teller
Timothy Nikkel
Butkovits Atila
Simon Giesecke
Nicklas Boman
Edgar Chen
Toshihito Kikuchi
Bob Owen
Jonathan Kew
Cosmin Sabou
Razvan Maries
Emilio Cobos Álvarez
Jonathan Watt
Tom Schuster
Emily McDonough
Erik Nordin
Bogdan Tara
Chun-Min Chang
Doug Thayer
alwu
Kartikaya Gupta
Mike Hommey
Mihai Alexandru Michis