This includes adding nsPrinterWin and nsPaperWin, so that we can retrieve
information from the printer device lazily.
Differential Revision: https://phabricator.services.mozilla.com/D84009
To enable Win32k lockdown, calls involving native theme will need to be
removed.
Currently these calls are scattered around several files. This class creates
a proxy for the Win32 calls. Whitelisting this class in awcw32ks makes it much
easier to track Win32k removal with themes removed.
As an added benefit, once non-native theming is done it will be easy to verify
by asserting that this class is never created in Content.
Differential Revision: https://phabricator.services.mozilla.com/D75946
There are a number of system parameters that return simple floats and bools
and are just different forms of system parameter query.
This introduces a new singleton and IPDL calls to send these values from parent
to content processes and cache them in content.
I started with these 2 variables because their values don't go stale. In a
later changeset, I will add more logic to invalidate cached values that go
stale, such as for the SPI_GETFLATMENU metric.
Differential Revision: https://phabricator.services.mozilla.com/D76639
Unfortunately, current on-screen keyboard (OSK) code in Gecko doesn't work on
current Windows 10. Actually, Windows automatically control OSK when getting
focus. But this isn't good for web browser since `inputmode` spec can close
OSK by `none` value.
Windows 10 RS1 has new API (IInputPane [*1]) to control software keyboard. So
we have to use it if OS is RS1 or later.
TSF has new flag as `TS_SD_INPUTPANEMANUALDISPLAYENABLE` not to control OSK by
TSF. We should use it.
IMM doesn't have this feature to manage OSK. This will become a limitation for
`inputmode` implementation.
[*1] https://docs.microsoft.com/en-us/uwp/api/windows.ui.viewmanagement.inputpane
Depends on D68314
Differential Revision: https://phabricator.services.mozilla.com/D68315
--HG--
extra : moz-landing-system : lando
Unfortunately, current on-screen keyboard (OSK) code in Gecko doesn't work on
current Windows 10. Actually, Windows automatically control OSK when getting
focus. But this isn't good for web browser since `inputmode` spec can close
OSK by `none` value.
Windows 10 RS1 has new API (IInputPane [*1]) to control software keyboard. So
we have to use it if OS is RS1 or later.
TSF has new flag as `TS_SD_INPUTPANEMANUALDISPLAYENABLE` not to control OSK by
TSF. We should use it.
IMM doesn't have this feature to manage OSK. This will become a limitation for
`inputmode` implementation.
[*1] https://docs.microsoft.com/en-us/uwp/api/windows.ui.viewmanagement.inputpane
Depends on D68314
Differential Revision: https://phabricator.services.mozilla.com/D68315
--HG--
extra : moz-landing-system : lando
This change adds new "remote backbuffer" logic when compositing without
HW acceleration on Windows (IE compositing through Cairo using the Win32
GDI)
A new piece of shared memory is created between the GPU process and the UI
process, and the GPU process sends requests to the UI process to first "borrow"
a properly-sized buffer to draw into, and then sends a "present" request to
tell the UI process to actually blit the buffer to the Win32 window.
This is needed for the GPU sandbox to work, since Windows rightly doesn't
allow the untrusted GPU process to directly draw the contents of a window
owned by the trusted UI process.
Differential Revision: https://phabricator.services.mozilla.com/D61370
--HG--
extra : moz-landing-system : lando
This change adds new "remote backbuffer" logic when compositing without
HW acceleration on Windows (IE compositing through Cairo using the Win32
GDI)
A new piece of shared memory is created between the GPU process and the UI
process, and the GPU process sends requests to the UI process to first "borrow"
a properly-sized buffer to draw into, and then sends a "present" request to
tell the UI process to actually blit the buffer to the Win32 window.
This is needed for the GPU sandbox to work, since Windows rightly doesn't
allow the untrusted GPU process to directly draw the contents of a window
owned by the trusted UI process.
Differential Revision: https://phabricator.services.mozilla.com/D61370
--HG--
extra : moz-landing-system : lando
This looks like a large change, but it's really just moving stuff
around.
It takes the logic in WinCompositorWidget and duplicates it into
its only 2 subclasses: InProcessWinCompositorWidget and
CompositorWidgetParent.
This is because CompositorWidgetParent is about to change *a lot*, but
InProcessWinCompositorWidget will basically stay the same. This is an
easy way to verify that I don't accidently break
InProcessWinCompositorWidget.
Differential Revision: https://phabricator.services.mozilla.com/D57428
--HG--
extra : moz-landing-system : lando
Create a general interface for getting platform-specific media keys event source in order to remove platform specific code from non-platform related folder `dom/media`.
Differential Revision: https://phabricator.services.mozilla.com/D55892
--HG--
rename : dom/media/mediacontrol/MediaHardwareKeysEventSourceMac.h => widget/cocoa/MediaHardwareKeysEventSourceMac.h
rename : dom/media/mediacontrol/MediaHardwareKeysEventSourceMac.mm => widget/cocoa/MediaHardwareKeysEventSourceMac.mm
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 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
This patch introduces a new module in widget that implements a simple API to
retrieve system information about a process and its threads.
This function is wrapped into ChromeUtils.RequestProcInfo to return information
about processes started by Firefox.
The use case for this API is to monitor Firefox resources usage in projects
like the battery usage done by the data science team.
Differential Revision: https://phabricator.services.mozilla.com/D10069
--HG--
extra : moz-landing-system : lando
This patch introduces a new module in widget that implements a simple API to
retrieve system information about a process and its threads.
This function is wrapped into ChromeUtils.RequestProcInfo to return information
about processes started by Firefox.
The use case for this API is to monitor Firefox resources usage in projects
like the battery usage done by the data science team.
Differential Revision: https://phabricator.services.mozilla.com/D10069
--HG--
extra : moz-landing-system : lando
Consequently, this removes:
- MOZ_LIBPRIO, which is now always enabled.
- non_msvc_compiler, which is now always true.
- The cl.py wrapper, since it's not used anymore.
- CL_INCLUDES_PREFIX, which was only used for the cl.py wrapper.
- NONASCII, which was only there to ensure CL_INCLUDES_PREFIX still
worked in non-ASCII cases.
This however keeps a large part of detecting and configuring for MSVC,
because we still do need it for at least headers, libraries, and midl.
Depends on D19614
Differential Revision: https://phabricator.services.mozilla.com/D19615
--HG--
extra : moz-landing-system : lando
Casting non-void result to `void*` causes warning of clang. Additionally,
perhaps, we should use `Unused <<` because of modern style.
And also this patch makes widget/windows is treated as "warning as errors"
because this patch fixes the last warning.
Differential Revision: https://phabricator.services.mozilla.com/D17216
--HG--
extra : moz-landing-system : lando
Implemnt notification backend by Windows Toast API that is from Windows 8+.
Original patch is me and add some features by eoger.
Differential Revision: https://phabricator.services.mozilla.com/D3003
--HG--
extra : rebase_source : 0368f269e9adb2347621500b7c9d62c172a71e39
Implemnt notification backend by Windows Toast API that is from Windows 8+.
Original patch is me and add some features by eoger.
Differential Revision: https://phabricator.services.mozilla.com/D3003
--HG--
extra : rebase_source : 5b73af9480569105c24baa5013e25879cbc68b02
