The `const` qualifier on `mVersion` was preventing move and copy, which we
now need this class to support.
Depends on D43158
Differential Revision: https://phabricator.services.mozilla.com/D43159
--HG--
extra : moz-landing-system : lando
We compare two file ids to check the current process is launched from the same
executable. However, our telemetry showed a number of Win7 users failed to open
a file handle of the parent process with STATUS_OBJECT_PATH_NOT_FOUND even
though we opened a process handle and retrieved a module path of the parent
process successfully. We don't have data to explain how this happens or why
this happens only on Win7, Win10 10240, and 10586.
To mitigate this situation, this patch introduces a logic to compare NT path
strings. The benefit from doing this is 1) we don't have to open a file handle
of a parent process executable and 2) when we get an NT path, a network drive
or a symbolic link is already solved.
This new logic is much faster, but we still compare file ids on the first
attempt to minimize the impact. We fall back to the new logic only if we
detect the STATUS_OBJECT_PATH_NOT_FOUND failure.
Differential Revision: https://phabricator.services.mozilla.com/D45476
--HG--
extra : moz-landing-system : lando
The `const` qualifier on `mVersion` was preventing move and copy, which we
now need this class to support.
Differential Revision: https://phabricator.services.mozilla.com/D43159
--HG--
extra : moz-landing-system : lando
The `const` qualifier on `mVersion` was preventing move and copy, which we
now need this class to support.
Differential Revision: https://phabricator.services.mozilla.com/D43159
--HG--
extra : moz-landing-system : lando
The `const` qualifier on `mVersion` was preventing move and copy, which we
now need this class to support.
Differential Revision: https://phabricator.services.mozilla.com/D43159
--HG--
extra : moz-landing-system : lando
`WindowsErrorResult` is a class to hold either a value or a Windows error
code based on the `Result` template. We also have `LauncherResult` for the
same purpose, which was introduced as a part of the launcher process feature
afterward. The difference is `LauncherResult` holds a filename and line
number along with an error code.
This patch integrates LauncherResult.h into WinHeaderOnlyUtils.h so that we
can use `LauncherResult` more broadly.
Differential Revision: https://phabricator.services.mozilla.com/D44512
--HG--
extra : moz-landing-system : lando
This change introduces plumbing for communicating with the GPU process through
VRShMem while bootstrapping Firefox for creating a window with Firefox Reality.
Test impact shows a fabricated value returned for the texture handle in VRShMem.
Differential Revision: https://phabricator.services.mozilla.com/D41383
--HG--
extra : moz-landing-system : lando
Most of things will likely be no real change because they ask for the exact frame they want immediately before.
Differential Revision: https://phabricator.services.mozilla.com/D44359
--HG--
extra : moz-landing-system : lando
4eca0f08c43b73dc1dd908fad58bdfd7f6973119 introduced dynamic linking of urlmon
for MinGW as a workaround. Now that MinGW was updated, we can remove that
workaround.
Differential Revision: https://phabricator.services.mozilla.com/D43281
--HG--
extra : moz-landing-system : lando
Converts dom.w3c_pointer_events.dispatch_by_pointer_messages to a static pref and removes its mirror variable.
Differential Revision: https://phabricator.services.mozilla.com/D43524
--HG--
extra : moz-landing-system : lando
Converts layout.css.devPixelsPerPx to a static pref. This one was one of the slightly odd ones; some values were expecting an atomic float, so instead of defining a regular type float it is defined in StaticPrefList.yaml as an AtomicFloat. I am assuming this was the intent of the pref value all along.
Differential Revision: https://phabricator.services.mozilla.com/D42396
--HG--
extra : moz-landing-system : lando
Until now, `WinUtils::PreparePathForTelemetry` did not whitelist paths
originating from the Windows system directory. This is unfortunate, as those
paths are not going to contain any PII yet may be useful for troubleshooting.
By adding `%SystemRoot%` to the whitelist, such paths will be included after
substituting the real system directory with the name of the environment
variable.
Finally, we need to lazily build the whitelist in a thread-safe manner.
Whitelist construction has been refactored so that the whitelist is a static
local variable that is atomically constructed.
Differential Revision: https://phabricator.services.mozilla.com/D42916
--HG--
extra : moz-landing-system : lando
ScreenPixels would be a more appropriate unit. But inside BasicCompositor everything
is in the same coordinate space anyway so we're not getting much benefit from the
units. This patch eliminates a lot of .ToUnknown*() calls.
Differential Revision: https://phabricator.services.mozilla.com/D41680
--HG--
extra : moz-landing-system : lando
On Windows, where the DrawTarget is rewrapped in a Cairo/pixman DrawTarget,
this will now cause Cairo/pixman to be used for the clear.
Differential Revision: https://phabricator.services.mozilla.com/D41673
--HG--
extra : moz-landing-system : lando
For launching with an external protocol handler on Windows, we validate a uri
before sending it to `ShellExecute`, by converting a string into `PIDL` using
`SHParseDisplayName` and extract a string back from PIDL using
`IShellFolder::GetDisplayNameOf`. The problem was that if a fragment, a
string following a hash mark (#), is always dropped after this validation.
This is caused by the intended design of Windows.
A proposed fix is to use `CreateUri` for validation, which is used behind
`IShellFolder::GetDisplayNameOf`. However, we also keep `SHParseDisplayName`
because there are cases where `CreateUri` succeeds while `SHParseDisplayName`
fails such as a non-existent `file:` uri and we want to keep the same
validation result for those cases.
Adding `CreateUri` broke MinGW build because of our toolkit issue. We use
dynamic linking for MinGW build in the meantime.
This patch adds a new unittest to make sure the new validation logic
behaves the same as the old one except the fragment issue.
Differential Revision: https://phabricator.services.mozilla.com/D42041
--HG--
extra : moz-landing-system : lando
For launching with an external protocol handler on Windows, we validate a uri
before sending it to `ShellExecute`, by converting a string into `PIDL` using
`SHParseDisplayName` and extract a string back from PIDL using
`IShellFolder::GetDisplayNameOf`. The problem was that if a fragment, a
string following a hash mark (#), is always dropped after this validation.
This is caused by the intended design of Windows.
A proposed fix is to use `CreateUri` for validation, which is used behind
`IShellFolder::GetDisplayNameOf`. However, we also keep `SHParseDisplayName`
because there are cases where `CreateUri` succeeds while `SHParseDisplayName`
fails such as a non-existent `file:` uri and we want to keep the same
validation result for those cases.
This patch adds a new unittest to make sure the new validation logic
behaves the same as the old one except the fragment issue.
Differential Revision: https://phabricator.services.mozilla.com/D42041
--HG--
extra : moz-landing-system : lando
This is needed to let WebRender run on ANGLE/WARP because we end up with
the Microsoft vendor.
Differential Revision: https://phabricator.services.mozilla.com/D41853
--HG--
extra : moz-landing-system : lando
Converts mozilla.widget.disable-native-theme varcache pref to a static pref and updates uses of its associated global variable with the pref. This also renames the pref to widget.disable-native-theme to group with other widget prefs.
Differential Revision: https://phabricator.services.mozilla.com/D40721
--HG--
extra : moz-landing-system : lando
These are now being hit because of the removal of the HTML frames
customizations to the print dialog.
I've removed the defines for these, because I don't think there is any point
trying to guess what their uses are.
I've also made it 32-bit only, because we only see them on 32-bit Windows 7.
In fact only 32-bit Firefox on 64-bit Windows 7 I believe.
Differential Revision: https://phabricator.services.mozilla.com/D40433
--HG--
extra : moz-landing-system : lando
`IShellWindows::FindWindowSW` may return the dreaded `S_FALSE`, so we need to
ensure that we're handling that.
I checked the remaining functions called by this code and none of the others
do this; this is the only call site that requires the check.
I'm not sure why we're seeing this error code. I added an explicit cast to
ensure that `CSIDL_DESKTOP` is being interpreted as an `int`, though I doubt
that this actually makes any difference.
Differential Revision: https://phabricator.services.mozilla.com/D39799
--HG--
extra : moz-landing-system : lando
This requires replacing inclusions of it with inclusions of more specific prefs
files.
The exception is that StaticPrefsAll.h, which is equivalent to StaticPrefs.h,
and is used in `Codegen.py` because doing something smarter is tricky and
suitable for a follow-up. As a result, any change to StaticPrefList.yaml will
still trigger recompilation of all the generated DOM bindings files, but that's
still a big improvement over trigger recompilation of every file that uses
static prefs.
Most of the changes in this commit are very boring. The only changes that are
not boring are modules/libpref/*, Codegen.py, and ServoBindings.toml.
Differential Revision: https://phabricator.services.mozilla.com/D39138
--HG--
extra : moz-landing-system : lando
For the URI handling case, we still want to parse the URI to look for any
malformation. OTOH, IShellDispatch2::ShellExecute does not accept PIDLs as
arguments, we we need an overload that converts the absolute PIDL back to a
path for the purposes of passing on to that interface.
Differential Revision: https://phabricator.services.mozilla.com/D38944
--HG--
extra : moz-landing-system : lando
This is just so that both the launcher process and other Gecko code can share
this method.
Differential Revision: https://phabricator.services.mozilla.com/D38943
--HG--
extra : moz-landing-system : lando
In bug 1551961, a WM_NCMOUSELEAVE message handler was added to the Windows widget
backend so that we can detect when the mouse leaves a draggable region (since
draggable regions are hittest'ed as HTCAPTION, and are therefore "non-client").
Inside that message handler, we used the WindowAtMouse handler to determine whether
or not the WM_NCMOUSELEAVE was firing because the mouse was moving off of the
non-client area to client area, or moving out of the window entirely.
For reasons that are not particularly clear, on Windows Aero Glass, when clicking on
one of the min/max/close caption buttons, a WM_NCMOUSELEAVE message fires, and the
::WindowFromPoint call that WindowAtMouse uses causes another WM_NCMOUSELEAVE message
to be queued immediately after, so we end up in this situation where the message
loop is getting spammed by WM_NCMOUSELEAVE messages. Moving the mouse away from
the caption buttons seems to stop the spamming.
We have a function similar to WindowAtMouse called EventIsInsideWindow which
does not use ::WindowFromPoint, and this seems to sidestep the issue, while
being functionally equivalent.
Depends on D37421
Differential Revision: https://phabricator.services.mozilla.com/D37422
--HG--
extra : moz-landing-system : lando
We need to do this in order to not override the mouse cursor that we set in the
widget layer when hit-testing in the non-client region.
We were accidentally overriding before because the PresShell normally queues up a
synthetic mousemove event when the mouse is moving within the client region. That
mousemove cause the EventStateManager to update the cursor to match Gecko's
reckoning of the cursor CSS style of the underlying frame (which overrides the
cursor we may have set in the Windows non-client region hittest - for example,
one of the window resize cursors).
By clearing the mMouseInDraggableArea boolean when transitioning from a draggable
to non-draggable region in the non-client region, we make sure that we process the
WM_MOUSELEAVE message, which sends the eMouseExitFromWidget event into Gecko, which
effectively cancels handling of the synthetic mousemove.
Differential Revision: https://phabricator.services.mozilla.com/D37421
--HG--
extra : moz-landing-system : lando
The patch also removes the layers.mlgpu.enable-container-resizing pref, because
it's dead.
Differential Revision: https://phabricator.services.mozilla.com/D36159
--HG--
extra : rebase_source : e215d584aed18f865d2e8d00a78e76e9b0323e6e
Adds GeckoChildProcessHost::GetAll() and use it in ChromeUtils::GetProcInfo()
Differential Revision: https://phabricator.services.mozilla.com/D33920
--HG--
extra : moz-landing-system : lando
Adds GeckoChildProcessHost::GetAll() and use it in ChromeUtils::GetProcInfo()
Differential Revision: https://phabricator.services.mozilla.com/D33920
--HG--
extra : moz-landing-system : lando
Adds GeckoChildProcessHost::GetAll() and use it in ChromeUtils::GetProcInfo()
Differential Revision: https://phabricator.services.mozilla.com/D33920
--HG--
extra : moz-landing-system : lando
Aaron Klotz
Toshihito Kikuchi
Brindusan Cristian
Ciure Andrei
Andreea Pavel
Brendan Dahl
thomasmo
Timothy Nikkel
Kristen Wright
Botond Ballo
Markus Stange
Razvan Maries
Jeff Muizelaar
Bob Owen
Nicholas Nethercote
Barret Rennie
Mike Conley
Narcis Beleuzu
Tarek Ziadé
arthur.iakab
Masatoshi Kimura
Oana Pop Rus
Gurzau Raul
Peter Van der Beken
Boris Zbarsky