Note that this makes Firefox use the standard system Print dialog as opposed
to just removing our "Frames" section from our custom dialog.
Differential Revision: https://phabricator.services.mozilla.com/D33389
--HG--
extra : rebase_source : a6d85b5c57bbc3ecd83135dae2581db56e8a7fab
It's only moved around, but not actually used anywhere.
I have no idea what this was supposed to control in the past but it doesn't seem
useful to keep it around.
Differential Revision: https://phabricator.services.mozilla.com/D33393
--HG--
extra : moz-landing-system : lando
Only gtk returns failure ever, and nobody checks the result anyway.
Use an enum class so that it's clear from the caller what it means.
Differential Revision: https://phabricator.services.mozilla.com/D32353
--HG--
extra : moz-landing-system : lando
Only gtk returns failure ever, and nobody checks the result anyway.
Use an enum class so that it's clear from the caller what it means.
Differential Revision: https://phabricator.services.mozilla.com/D32353
--HG--
extra : moz-landing-system : lando
And with some tidying some comments and removing stray #include "gfxPrefs.h"
Differential Revision: https://phabricator.services.mozilla.com/D31468
--HG--
extra : moz-landing-system : lando
gfxPrefs Live preferences are almost identical to StaticPrefs.
We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D31256
--HG--
extra : moz-landing-system : lando
This should be an idempotent patch. The way to come up with this patch has been:
* Run the first script attached to the bug and pipe it to xclip, then paste it
in color.rs
* Add the relevant #[derive] annotations and remove the color.mako.rs
definition.
* Reorder the values to match the ColorID definition, on which some widget
prefs and caching stuff relies on.
* Manually port some documentation from nsLookAndFeel.h
* Run `rg 'eColorID_' | cut -d : -f 1 | sort | uniq >files`
* Run the second script attached to the bug.
* Manually fix usage of `LAST_COLOR` (adding the `End` variant), and adding
casts to integer as needed.
* Add an static assert so that people remember to update the prefs, rather than
a comment on the definition :)
Differential Revision: https://phabricator.services.mozilla.com/D32610
--HG--
extra : moz-landing-system : lando
And with some tidying some comments and removing stray #include "gfxPrefs.h"
Differential Revision: https://phabricator.services.mozilla.com/D31468
--HG--
extra : moz-landing-system : lando
gfxPrefs Live preferences are almost identical to StaticPrefs.
We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D31256
--HG--
extra : moz-landing-system : lando
And with some tidying some comments and removing stray #include "gfxPrefs.h"
Differential Revision: https://phabricator.services.mozilla.com/D31468
--HG--
extra : moz-landing-system : lando
gfxPrefs Live preferences are almost identical to StaticPrefs.
We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D31256
--HG--
extra : moz-landing-system : lando
ClientMarginHitTestPoint takes into account the fact that we want a minimum
of kResizableBorderMinSize pixels thickness around the window to trigger
resizing.
Differential Revision: https://phabricator.services.mozilla.com/D30427
--HG--
extra : moz-landing-system : lando
This reunifies the behaviour changed in bug 1294232 to ensure that the
vendor ID of GfxInfo is the same between graphics hardware. Vendor ID
should always represent Intel, Nvidia, ATI, etc such that callers can
reason about the performance characteristics without being exposed to
the driver implementation for that platform. Now we split off the more
detailed driver information into the "driver vendor" which will contain
more information, such as what implementation is being used (e.g.
mesa/i965 for modern Intel graphics cards). This field is exposed to the
blocklist and will be useful for allowing different rules for different
driver implementations.
We also now provide a default implementation for
GfxInfoBase::FindMonitors for platforms missing support. This will just
list the primary screen size used without listing secondary monitors,
refresh rate, and such.
Differential Revision: https://phabricator.services.mozilla.com/D29471
This reunifies the behaviour changed in bug 1294232 to ensure that the
vendor ID of GfxInfo is the same between graphics hardware. Vendor ID
should always represent Intel, Nvidia, ATI, etc such that callers can
reason about the performance characteristics without being exposed to
the driver implementation for that platform. Now we split off the more
detailed driver information into the "driver vendor" which will contain
more information, such as what implementation is being used (e.g.
mesa/i965 for modern Intel graphics cards). This field is exposed to the
blocklist and will be useful for allowing different rules for different
driver implementations.
We also now provide a default implementation for
GfxInfoBase::FindMonitors for platforms missing support. This will just
list the primary screen size used without listing secondary monitors,
refresh rate, and such.
Differential Revision: https://phabricator.services.mozilla.com/D29471
This reunifies the behaviour changed in bug 1294232 to ensure that the
vendor ID of GfxInfo is the same between graphics hardware. Vendor ID
should always represent Intel, Nvidia, ATI, etc such that callers can
reason about the performance characteristics without being exposed to
the driver implementation for that platform. Now we split off the more
detailed driver information into the "driver vendor" which will contain
more information, such as what implementation is being used (e.g.
mesa/i965 for modern Intel graphics cards). This field is exposed to the
blocklist and will be useful for allowing different rules for different
driver implementations.
We also now provide a default implementation for
GfxInfoBase::FindMonitors for platforms missing support. This will just
list the primary screen size used without listing secondary monitors,
refresh rate, and such.
Differential Revision: https://phabricator.services.mozilla.com/D29471
This driver version is known to have busg which cause the output of green
frames from the decoder, and to cause BSODs.
Differential Revision: https://phabricator.services.mozilla.com/D29603
--HG--
extra : moz-landing-system : lando
Moved mozilla::WidgetMosueEventBase::buttonType in MouseEvents.h to mozilla::MouseButton in EventForwards.h, and mozilla::WidgetMouseEventBase::buttonsFlag to mozilla::MouseButtonsFlag so that any referer in header files do not need to include MouseEvents.h only for referring them. Instead, they just need to include EventForwards.h. Now when MouseEvents.h is changed, the rebuild speed becomes faster.
Differential Revision: https://phabricator.services.mozilla.com/D25325
--HG--
extra : moz-landing-system : lando
Renamed all class member instances from WidgetMouseEventBase::inputSource to WidgetMouseEventBase::mInputSource
Differential Revision: https://phabricator.services.mozilla.com/D25322
--HG--
extra : moz-landing-system : lando
Renamed all class member instances from WidgetMouseEventBase::pressure to WidgetMouseEventBase::mPressure
Differential Revision: https://phabricator.services.mozilla.com/D25314
--HG--
extra : moz-landing-system : lando
Renamed all class member instances from WidgetMouseEventBase::button to WidgetMouseEventBase::mButton.
Differential Revision: https://phabricator.services.mozilla.com/D25309
--HG--
extra : moz-landing-system : lando
Renamed all class member instances from WidgetMouseEventBase::buttons to WidgetMouseEventBase::mButtons
Differential Revision: https://phabricator.services.mozilla.com/D25297
--HG--
extra : moz-landing-system : lando
The maximum size of an IPC message is defined twice; IPC::Channel::kMaximumMessageSize = 256 MiB and IPC::MAX_MESSAGE_SIZE = 65 KiB . The latter one is used for Windows printing and its small size could cause errors.
I removed the small constant, and made changes to the files using it :
- The windows printing file now uses kMaximumMessageSize / 2
- nsWebBrowserPersist uses its old constant
Differential Revision: https://phabricator.services.mozilla.com/D24972
--HG--
extra : moz-landing-system : lando
Bug 1525183 imported chromium workaround. But it caused a device specific regression. The change removes WS_EX_LAYERED and WS_EX_TRANSPARENT, but it keeps WS_EX_NOREDIRECTIONBITMAP, since it is necessary for memory usage reduction.
Differential Revision: https://phabricator.services.mozilla.com/D27461
--HG--
extra : moz-landing-system : lando
This patch makes `nsViewManager::GetPresShell()` and
`nsIWidgetListener::GetPresShell()` (overridden by `nsView` and
`nsWebShellWindow::WidgetListenerDelegate`) return `mozilla::PresShell*`.
Additionally, makes `nsWebShellWindow::GetPresShell()` also return
`mozilla::PresShell()`.
Differential Revision: https://phabricator.services.mozilla.com/D26454
--HG--
extra : moz-landing-system : lando
Linux machines using Intel graphics with Mesa drivers being at least
18.2.8.0 and not 4k displays should be able to run WebRender well, given
this is a common configuration used for testing already by Mozilla. This
patch allows users meeting said requirements to join the WebRender
experiments on nightly. WebRender will remain disabled by default for
other configurations/devices.
Differential Revision: https://phabricator.services.mozilla.com/D26796
Linux machines using Intel graphics with Mesa drivers being at least
18.2.8.0 and not 4k displays should be able to run WebRender well, given
this is a common configuration used for testing already by Mozilla. This
patch allows users meeting said requirements to join the WebRender
experiments on nightly. WebRender will remain disabled by default for
other configurations/devices.
Differential Revision: https://phabricator.services.mozilla.com/D26796
Originally, RDD reused the GPU process selector since they were
using all the same services, and it reduced the number of places
that had to be touched. Now that RDD needs pref handling, it
needs its own process selector to avoid GPU inheriting pref
handling.
Differential Revision: https://phabricator.services.mozilla.com/D26566
--HG--
extra : moz-landing-system : lando
Except retrieving from weak reference, `nsIFrame` should treat
`mozilla::PresShell` directly rather than via `nsIPresShell`.
Differential Revision: https://phabricator.services.mozilla.com/D26388
--HG--
extra : moz-landing-system : lando
A lot of files include `nsIPresShell.h` even though currently they don't
need it. This patch removes the unnecessary inclusions.
Differential Revision: https://phabricator.services.mozilla.com/D25744
--HG--
extra : moz-landing-system : lando
A lot of files include `nsIPresShell.h` even though currently they don't
need it. This patch removes the unnecessary inclusions.
Differential Revision: https://phabricator.services.mozilla.com/D25744
--HG--
extra : moz-landing-system : lando
* Removed dead code.
* Removed a duplicated field (`m_cRef`) from the derived class.
* Removed #ifdefs for older SDKs that we no longer support.
* Made access specifiers more restrictive.
* Added `override` and `final`.
* De-virtualized member functions unless it is neccessary.
Differential Revision: https://phabricator.services.mozilla.com/D21864
--HG--
extra : moz-landing-system : lando
AutoVirtualProtect will be useful for following patches. This moves it out of
DllBlocklistWin.cpp and into WinHeaderOnlyUtils.h so it can be shared.
Differential Revision: https://phabricator.services.mozilla.com/D13197
--HG--
extra : moz-landing-system : lando
By this change, icons will never be shrunk to a smaller size. Windows will do
it appropriately.
Internet Explorer's icon handler will not paint the white background if the
icon is large enough. I'm also replicating the behavior.
--HG--
extra : source : 56eb23aaff3a5a0dbca8e41c534307c30e7351f4
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
We didn't dispatch keyboard events during composition. Therefore, we tried to
retrieve raw virtual keycode value when key messages come with `VK_PROCESS`
unexpectedly. However, the API, `ImmGetVirtualKey()`, is not usable for this
purpose because it always returns `VK_PROCESS` if the key messages have already
been handled by IME. So, we can just stop using it since we need to expose
such key messages as KeyboardEvent whose `key` value is `Process` and `keyCode`
value is `DOM_VK_PROCESS`.
Differential Revision: https://phabricator.services.mozilla.com/D20623
--HG--
extra : moz-landing-system : lando
There seem to be a number of problems with Direct2D on the Qualcomm
devices. This includes visual corruption from bug 1515823 and crashes
in CHwRasterizer::RasterizeEdges from 1515387.
In order to get the alpha channel when encoding BMP images from a
surface, we need to supply bmp=32 in the encoder options.
Differential Revision: https://phabricator.services.mozilla.com/D19835
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
This patch takes care of a bunch of issues and does some cleanup:
* We rename mscom::MainThreadRuntime to mscom::ProcessRuntime, as the latter
is a more accurate name going forward.
* We make ProcessRuntime aware of the Win32k Lockdown process mitigation
policy. When Win32k is disabled, we perform process-wide COM initialization
in the multi-threaded apartment (since we cannot create an STA window).
* We refactor the mscom apartment region stuff to enable the Win32k lockdown
pieces in ProcessRuntime.
* We move some Gecko-specific stuff into MOZILLA_INTERNAL_API guards so that
ProcessRuntime is usable outside of xul.dll (I will be needing it for the
launcher process).
* Another thing that might happen with the launcher process is that, under
error conditions in the launcher, we create a ProcessRuntime object on a
background thread for the purposes of telemetry logging, but we also allow
the main thread to proceed to start as the browser. This could result in a
scenario where the main thread, as the browser process, is attempting to
instantiate its ProcessRuntime and ends up racing with the launcher process's
telemetry thread which has its own ProcessRuntime. To account for this
situation, we add mutual exclusion to the process-wide initialization code.
We host this part inside mozglue since that state is shared between both
firefox.exe and xul.dll.
* We clean up ProcessRuntime::InitializeSecurity by using Vector to set up
the EXPLICIT_ACCESS entries.
* We remove mscom::MainThreadClientInfo and replace it with a direct call to
CoGetCallerTID
* We revise all references to this class to use the new name.
Differential Revision: https://phabricator.services.mozilla.com/D19551
--HG--
rename : ipc/mscom/COMApartmentRegion.h => ipc/mscom/ApartmentRegion.h
rename : ipc/mscom/MainThreadRuntime.cpp => ipc/mscom/ProcessRuntime.cpp
rename : ipc/mscom/MainThreadRuntime.h => ipc/mscom/ProcessRuntime.h
extra : moz-landing-system : lando
This patch takes care of a bunch of issues and does some cleanup:
* We rename mscom::MainThreadRuntime to mscom::ProcessRuntime, as the latter
is a more accurate name going forward.
* We make ProcessRuntime aware of the Win32k Lockdown process mitigation
policy. When Win32k is disabled, we perform process-wide COM initialization
in the multi-threaded apartment (since we cannot create an STA window).
* We refactor the mscom apartment region stuff to enable the Win32k lockdown
pieces in ProcessRuntime.
* We move some Gecko-specific stuff into MOZILLA_INTERNAL_API guards so that
ProcessRuntime is usable outside of xul.dll (I will be needing it for the
launcher process).
* Another thing that might happen with the launcher process is that, under
error conditions in the launcher, we create a ProcessRuntime object on a
background thread for the purposes of telemetry logging, but we also allow
the main thread to proceed to start as the browser. This could result in a
scenario where the main thread, as the browser process, is attempting to
instantiate its ProcessRuntime and ends up racing with the launcher process's
telemetry thread which has its own ProcessRuntime. To account for this
situation, we add mutual exclusion to the process-wide initialization code.
We host this part inside mozglue since that state is shared between both
firefox.exe and xul.dll.
* We clean up ProcessRuntime::InitializeSecurity by using Vector to set up
the EXPLICIT_ACCESS entries.
* We remove mscom::MainThreadClientInfo and replace it with a direct call to
CoGetCallerTID
* We revise all references to this class to use the new name.
Differential Revision: https://phabricator.services.mozilla.com/D19551
--HG--
rename : ipc/mscom/COMApartmentRegion.h => ipc/mscom/ApartmentRegion.h
rename : ipc/mscom/MainThreadRuntime.cpp => ipc/mscom/ProcessRuntime.cpp
rename : ipc/mscom/MainThreadRuntime.h => ipc/mscom/ProcessRuntime.h
extra : moz-landing-system : lando
The only caller wants CSS pixels, no need to go back and forth.
This is the last dependency on the pres context, I think, from the style system
font code.
Differential Revision: https://phabricator.services.mozilla.com/D19147
Replacing js and text occurences of asyncOpen2
Replacing open2 with open
Differential Revision: https://phabricator.services.mozilla.com/D16885
--HG--
rename : layout/style/test/test_asyncopen2.html => layout/style/test/test_asyncopen.html
extra : moz-landing-system : lando
Chromium does workaround for scrolling with touch and avoid bitmap allocation when child window is used for DirectComposition. It improves performance of WebRender.
Differential Revision: https://phabricator.services.mozilla.com/D18659
During security.sandbox.gpu.level=1, compositor window's parent cannot be set in GPU process, it needs to be set in UI process.
Differential Revision: https://phabricator.services.mozilla.com/D18811
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
This stops the use of some win32k calls during start-up that will fail and in
some cases cause a crash.
It also moves the MITIGATION_DYNAMIC_CODE_DISABLE to be enabled after start-up.
This is required because the hooks to fake the user32 and gdi32 initialization
are applied as the DLLs load and the dynamic code disable blocks that.
This cleans up a bit and allows us to be smarter about which cursors
should we allow from content or what not, which will help with bug 1445844 and
co.
Differential Revision: https://phabricator.services.mozilla.com/D16711
DisplaySystemMenu() does not handle nsSizeMode_Invalid that causes warning of
clang. This patch makes it treat nsSizeMode_Invalid. When it receives the
value, it will call NS_ASSERTION() to be detectable on debug builds during
automated tests.
Additionally, this adds default case into the switch statement with
MOZ_ASSERT_UNREACHABLE(). Then, when somebody adds new nsSizeMode, they
can detect it with crash in debug build if they forget to change this method.
Differential Revision: https://phabricator.services.mozilla.com/D17217
--HG--
extra : moz-landing-system : lando
The method was added by bug 506926, but not sure when this becomes an orphan.
Differential Revision: https://phabricator.services.mozilla.com/D17215
--HG--
extra : moz-landing-system : lando
nsDataObj::GetDib() calls GetLastError() API immediately after calling
GlobalAlloc() and just return E_FAIL in such case. So, we don't need to
call it.
Differential Revision: https://phabricator.services.mozilla.com/D17214
--HG--
extra : moz-landing-system : lando
Because we don't know when the PlaySound API stop/finish playing. So when starting to play a sound, we should call PlaySound(0,0,PURGE) to stop playing then free the last data sound.
Differential Revision: https://phabricator.services.mozilla.com/D14554
--HG--
extra : moz-landing-system : lando
I needed to scale the layout device pixels coming from Windows before passing them to ScreenForRect(). Also, I'm using GetRect() directly instead of GetRectDisplayPix() * scale now, to avoid an unnecessary double scale & round which was making fullscreen windows off by one pixel in many cases.
Differential Revision: https://phabricator.services.mozilla.com/D15604
--HG--
extra : moz-landing-system : lando
gfxUtils::EncodeSourceSurface no longer uses a stringly-typed API to create a
`imgIEncoder` for the relevant MIME type. Instead, we now use an enum class and
switch on it to create the encoder.
Depends on D14816
Differential Revision: https://phabricator.services.mozilla.com/D14817
--HG--
extra : moz-landing-system : lando
Port to separate SpatialId from ClipId in Webrender API (WR PR #3251).
Patch was originally written and reviewed on bug 1503447.
Depends on D16005
Differential Revision: https://phabricator.services.mozilla.com/D16006
--HG--
extra : moz-landing-system : lando
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
Native toast notification uses WinUtils::WriteBitmap to bitmap for notification now. Since it uses old BITMAPINFOHEADER structure, it doesn't support alpha.
So I would like to support alpha value to WinUtils::WriteBitmap.
Differential Revision: https://phabricator.services.mozilla.com/D14670
--HG--
extra : moz-landing-system : lando
IMMHandler and TSFTextStore are good class to put native caret when they have
enough information. However, for example, IMMHandler may not have its singleton
instance until first composition of IMM-IME starts. Therefore, typically,
IMEHandler is a good class to put native caret without composition.
This patch adds IMEHandler::MaybeCreateNativeCaret(), and if it won't create
native caret because not yet received WM_GETOBJCT for OBJID_CARET, we should
fire window event for MSAA applications. If there is new MSAA application
retrieves OBJID_CARET, we'll receive WM_GETOBJECT for OBJID_CARET
asynchronously. Then, we should start to put native caret for such
applications.
Note that if we create native caret, some versions of ATOK refers the native
caret and the behavior becomes worse than usual. Therefore, we need to
keep not using native caret as far as possible.
Differential Revision: https://phabricator.services.mozilla.com/D13962
--HG--
extra : moz-landing-system : lando
If WM_GETOBJECT for OBJID_CARET is received but a11y module is not active,
IME module should create native caret over our caret because Windows will
handle the request with native caret automatically and we don't need to
enable a11y module only for it.
This patch makes IMEHandler store whether such message has been received and
makes TSFTextStore create native caret when composition, selection or layout
is changed because especially when there is composition, only TSFTextStore
knows correct position to put caret if there is composition or some dispatched
events have not been handled by content process yet.
Note that IMMHandler already does that since some legacy IMEs require native
caret to show its UI and we cannot check active IME strictly. Therefore, this
patch does not touch IMMHandler.
Differential Revision: https://phabricator.services.mozilla.com/D13961
--HG--
extra : moz-landing-system : lando
IMEHandler needs to create native caret later (when there is no composition).
Therefore, IMEHandler should manage whether it creates native caret or not
and IMMHandler and TSFTextStore should create/destroy native caret via
IMEHandler.
Note that this patch makes IMMHandler stops managing whether native caret
is created for plugin or not because native caret is created only one instance
and anyway IME handlers should stop managing native caret when they loses
focus.
Differential Revision: https://phabricator.services.mozilla.com/D13960
--HG--
extra : moz-landing-system : lando
If a11y module is active, it observers caret position and size, and when caret
position or size is changed, it creates/moves native caret to overlap with
our caret.
On the other hand, IME module also creates native caret if active IME requires
it. Therefore, both of them conflicts each other.
This patch makes IME module stop touching native caret if a11y module is active.
Although, a11y module with Flush Player does not work well for IME. Therefore,
this patch keeps the conflict between them as-is for now.
Differential Revision: https://phabricator.services.mozilla.com/D13959
--HG--
extra : moz-landing-system : lando
If TSFTextStore fails to get selection, e.g., the content is really odd like
fuzzing tests, its mSelectionForTSF is marked as dirty. However, Windows may
try to retrieve writing mode while we're creating new TSFTextStore. Then, we
may hit MOZ_ASSERT(!mDirty) in TSFTextStore::Selection::GetWritingMode() in
debug build.
So, we need to make some callers of GetWritingMode() check whether selection
is marked as dirty.
Differential Revision: https://phabricator.services.mozilla.com/D14137
--HG--
extra : moz-landing-system : lando
This is a best effort attempt at ensuring that the adverse impact of
reformatting the entire tree over the comments would be minimal. I've used a
combination of strategies including disabling of formatting, some manual
formatting and some changes to formatting to work around some clang-format
limitations.
Differential Revision: https://phabricator.services.mozilla.com/D13371
--HG--
extra : moz-landing-system : lando
This patch does a couple of things:
* I added a new class, |WindowsError| to WinHeaderOnlyUtils. The idea here is
to encapsulate as much of the Windows error gamut as possible into one class.
Since Win32 errors and NTSTATUS codes may both be encoded as HRESULTs, I
used the latter type to store the error. It also contains functions for
converting between the various error code formats, as well as stringification
via FormatMessage.
* I added |LauncherError| which also includes file and line number information,
which I believe will be important for launcher process failure diagnostics.
(Instantiation of LauncherErrors obviously must be done via macros to capture
__FILE__ and __LINE__).
* I then converted all of the launcher process code (and its few depenencies) to
utilize this new functionality via the new |LauncherResult| type.
* If we detect an error in one of the top-level launcher process functions, we
pass it to |HandleLauncherError| for processing. This function currently just
throws up a |MessageBox| like the previous code did, with the intention of
enhancing that further in the future.
Differential Revision: https://phabricator.services.mozilla.com/D12365
--HG--
extra : moz-landing-system : lando
This patch does a couple of things:
* I added a new class, |WindowsError| to WinHeaderOnlyUtils. The idea here is
to encapsulate as much of the Windows error gamut as possible into one class.
Since Win32 errors and NTSTATUS codes may both be encoded as HRESULTs, I
used the latter type to store the error. It also contains functions for
converting between the various error code formats, as well as stringification
via FormatMessage.
* I added |LauncherError| which also includes file and line number information,
which I believe will be important for launcher process failure diagnostics.
(Instantiation of LauncherErrors obviously must be done via macros to capture
__FILE__ and __LINE__).
* I then converted all of the launcher process code (and its few depenencies) to
utilize this new functionality via the new |LauncherResult| type.
* If we detect an error in one of the top-level launcher process functions, we
pass it to |HandleLauncherError| for processing. This function currently just
throws up a |MessageBox| like the previous code did, with the intention of
enhancing that further in the future.
Differential Revision: https://phabricator.services.mozilla.com/D12365
--HG--
extra : moz-landing-system : lando
This patch does a couple of things:
* I added a new class, |WindowsError| to WinHeaderOnlyUtils. The idea here is
to encapsulate as much of the Windows error gamut as possible into one class.
Since Win32 errors and NTSTATUS codes may both be encoded as HRESULTs, I
used the latter type to store the error. It also contains functions for
converting between the various error code formats, as well as stringification
via FormatMessage.
* I added |LauncherError| which also includes file and line number information,
which I believe will be important for launcher process failure diagnostics.
(Instantiation of LauncherErrors obviously must be done via macros to capture
__FILE__ and __LINE__).
* I then converted all of the launcher process code (and its few depenencies) to
utilize this new functionality via the new |LauncherResult| type.
* If we detect an error in one of the top-level launcher process functions, we
pass it to |HandleLauncherError| for processing. This function currently just
throws up a |MessageBox| like the previous code did, with the intention of
enhancing that further in the future.
Differential Revision: https://phabricator.services.mozilla.com/D12365
--HG--
extra : moz-landing-system : lando
This patch does a couple of things:
* I added a new class, |WindowsError| to WinHeaderOnlyUtils. The idea here is
to encapsulate as much of the Windows error gamut as possible into one class.
Since Win32 errors and NTSTATUS codes may both be encoded as HRESULTs, I
used the latter type to store the error. It also contains functions for
converting between the various error code formats, as well as stringification
via FormatMessage.
* I added |LauncherError| which also includes file and line number information,
which I believe will be important for launcher process failure diagnostics.
(Instantiation of LauncherErrors obviously must be done via macros to capture
__FILE__ and __LINE__).
* I then converted all of the launcher process code (and its few depenencies) to
utilize this new functionality via the new |LauncherResult| type.
* If we detect an error in one of the top-level launcher process functions, we
pass it to |HandleLauncherError| for processing. This function currently just
throws up a |MessageBox| like the previous code did, with the intention of
enhancing that further in the future.
Differential Revision: https://phabricator.services.mozilla.com/D12365
--HG--
extra : moz-landing-system : lando
Right now CreateDataFromPrimitive doesn't use the aDataLen parameter, and after this change the out
value should be the same as the value passed in, as long as we are dealing with strings.
Differential Revision: https://phabricator.services.mozilla.com/D10718
--HG--
extra : moz-landing-system : lando
Keep our old 'progressbar' as an alias for now, but unship
'progresschunk' by restricting it to UA/chrome sheets only.
Unship 'progresschunk-vertical' by removing it since it's
not used internally for anything.
A wrapper for ::GetModuleFileNameW() is needed in multiple places for the
purpose of evaluating and processing untrusted DLLs. This adds the appropriate
wrapper to WinUtils.cpp
Depends on D6240
Differential Revision: https://phabricator.services.mozilla.com/D9163
--HG--
extra : moz-landing-system : lando
Bug 1435827 part 3/9: Add WinUtils::PreparePathForTelemetry;r=aklotz
PreparePathForTelemetry encapsulates our method of removing sensitive
information from file paths for use in telemetry payloads.
SanitizePath() has been essentially renamed to PreparePathForTelemetry()
which is a bit more precise now that it's being used externally.
Untrusted modules evaluation requires a few path transformations to happen at
various places during processing. This is largely because APIs like
GetLongPathNameW can be rather slow, so performance becomes an issue.
That is the justification for breaking out path transformations into separate
wrapper functions and also the need for PathFlags.
Differential Revision: https://phabricator.services.mozilla.com/D6240
--HG--
extra : moz-landing-system : lando
We already have a check for the nvidia vendor id in gfxPlatform.cpp so
we don't need to list all the other vendors explicitly.
Differential Revision: https://phabricator.services.mozilla.com/D9677
--HG--
extra : moz-landing-system : lando
When clicking toast notification window, OnActivate is called. When using
Windows 8, 2nd parameter (IInspectable) might be nullptr.
So when this parameter is nullptr, it should recognize as alertclickcallback
with mClickable=true.
Differential Revision: https://phabricator.services.mozilla.com/D8076
--HG--
extra : moz-landing-system : lando
We currently allow the GPU process if we are not hardware accelerated. One of the
reasons we might not use hardware acceleration is because the device vendor is
not in the gfxInfo whitelist. In this case, we should be consistent and still
use the GPU process.
Differential Revision: https://phabricator.services.mozilla.com/D9446
--HG--
extra : moz-landing-system : lando
It seems some touchscreen devices are recognized as an HID not a mouse, so
for such devices we need to use GUID_DEVINTERFACE_HID instead.
I've confirmed that WM_DEVICECHANGE is received when a mouse is
connected/disconnected on a Thinkpad even if we use GUID_DEVINTERFACE_HID here.
Differential Revision: https://phabricator.services.mozilla.com/D8526
--HG--
extra : moz-landing-system : lando
Jonathan Watt
Emilio Cobos Álvarez
Boris Zbarsky
Brindusan Cristian
Andrew Osmond
Jean-Yves Avenard
Gurzau Raul
Mike Conley
Masayuki Nakano
Mihai Alexandru Michis
Daniel Varga
Chris Pearce
Sylvestre Ledru
Ryan Hunt
Srujana Peddinti
Kartikaya Gupta
hafsa
sotaro
Csoregi Natalia
Coroiu Cristina
Michael Froman
Narcis Beleuzu
Cosmin Sabou
Razvan Maries
Alex Gaynor
Jim Mathies
Masatoshi Kimura
Bogdan Tara
meandave
Andrew Comminos
Dorel Luca
David Major
Andrea Marchesini
Ciure Andrei
Adam Gashlin
Carl Corcoran
Felipe Gomes
Jonathan Kingston
Tarek Ziadé
Jeff Muizelaar
Jeff Walden
Kris Maglione
arthur.iakab
Mike Hommey
Aaron Klotz
Jorg K
Edgar Chen
Bob Owen
Ehsan Akhgari
Dragana Damjanovic
Thomas Nguyen
Xidorn Quan
Barret Rennie
Dzmitry Malyshau
Tom Schuster
Makoto Kato
Florian Quèze
Tooru Fujisawa
Andreea Pavel
Gabriele Svelto
Mats Palmgren
Lee Salzman
Daosheng Mu
shindli
Jeff Gilbert
Dale Harvey
Hiroyuki Ikezoe