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
It just doesn't work.
We add the preference media.wmf.force.allow-p010-format to force enable it.
Depends on D8136
Differential Revision: https://phabricator.services.mozilla.com/D8310
--HG--
extra : moz-landing-system : lando
nsNativeThemeWin.cpp has a lot of warnings at build time. They hides preceding
errors and warning due to too many. This patch avoids the warnings with:
- adding |default| case of each |switch| statement with widget type.
- removing unused overload of ScaleForFrameDPI().
Differential Revision: https://phabricator.services.mozilla.com/D8055
--HG--
extra : moz-landing-system : lando
The main benefit of doing this is that if semi-transparent colors are
specified on scrollbar-color, they can blend natively with underlying
content. This may match authors' expectation better.
Differential Revision: https://phabricator.services.mozilla.com/D7154
--HG--
extra : moz-landing-system : lando
QueryFullProcessImageNameW may fail in some environments when dwFlags is zero
due to NT-to-DOS path conversions. CreateFile will convert the argumant back to
an NT path anyway.
--HG--
extra : source : 54778cf89825c24f656fcf8ebcef5aa3bf4e6839
extra : intermediate-source : b40d295b3c43d5cffa453bc0536af2bada4eeac2
Unfortunately there is no realiable way to tell whether there is no mouse
connected or not. So we are going to take a heuristic way here. The way is
that;
1) Count mouse type devices with SetupDiEnumDeviceInterfaces [1]
2) If the count is 1 and if the system is used as tablet or has a touch device,
the device should be COARSE
This way causes a misrecognition as if there is a mouse device in the case
where the touchscreen is disabled on the tablet even if there is no mouse
connected (i.e. the case where CountMouseDevices() returns 1 and the system
is on table mode). We will try to fix the misrecognition in a later bug
(bug 1495938).
[1] https://docs.microsoft.com/en-us/windows/desktop/api/setupapi/nf-setupapi-setupdienumdeviceinterfaces
Differential Revision: https://phabricator.services.mozilla.com/D7565
--HG--
extra : moz-landing-system : lando
Unfortunately there is no realiable way to tell whether there is no mouse
connected or not. So we are going to take a heuristic way here. The way is
that;
1) Count mouse type devices with SetupDiEnumDeviceInterfaces [1]
2) If the count is 1 and if the system is used as tablet or has a touch device,
the device should be COARSE
This way causes a misrecognition as if there is a mouse device in the case
where the touchscreen is disabled on the tablet even if there is no mouse
connected (i.e. the case where CountMouseDevices() returns 1 and the system
is on table mode). We will try to fix the misrecognition in a later bug
(bug 1495938).
[1] https://docs.microsoft.com/en-us/windows/desktop/api/setupapi/nf-setupapi-setupdienumdeviceinterfaces
Differential Revision: https://phabricator.services.mozilla.com/D7565
--HG--
extra : moz-landing-system : lando
Since some filesystems do not support FileIdInfo, we can't assume that it will
succeed even on Windows 8 or later.
--HG--
extra : source : 00c79940244f7a57d77db186996533cd5589c4ea
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
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
WriteBitmap will be used for Toast implementation, so it should be moved to
WinUtils.
Differential Revision: https://phabricator.services.mozilla.com/D3002
--HG--
extra : rebase_source : 7ec7593fd0294dcaa6aab5e8f503b5aa752cb9d1
WriteBitmap will be used for Toast implementation, so it should be moved to
WinUtils.
Differential Revision: https://phabricator.services.mozilla.com/D3002
--HG--
extra : rebase_source : b418288b52e14f62122f56dbc40e771c73fd6414
Note that this dynamic change will not work without a patch for bug 1478576
if user doesn't touch browser windows.
Differential Revision: https://phabricator.services.mozilla.com/D3301
This patch initializes some HAL components greedily so that we can get rid of
lazy initializers within the code. Observers are still lazily initialized
because they can be instanced within content processes but that doesn't always
happen and we don't want to pay the memory price for structures we don't use.
Shutdown is now happening at a fixed time for all HAL components save
WakeLocks. This ensures that we don't destroy an object while still iterating
over it, something that could happen before.
Finally a workaround for a compiler limitation has been removed.
Differential Revision: https://phabricator.services.mozilla.com/D3100
--HG--
extra : moz-landing-system : lando
The fix in bug 1418793 accidentally removed the onCloseWindow call, which
meant we were setting `.enabled` on taskbar window objects whose windows
were already dead, which was causing crashes.
I've reverted the removal, and also added some nullchecking, because the
C++ component shouldn't make it this easy for consumers to cause crashes.
Differential Revision: https://phabricator.services.mozilla.com/D4559
--HG--
extra : moz-landing-system : lando
There are surprisingly many of them.
(Plus a couple of unnecessary checks after `new` calls that were nearby.)
--HG--
extra : rebase_source : 47b6d5d7c5c99b1b50b396daf7a3b67abfd74fc1
This allows JS callers to automatically get the correct types during
interation, without having to explicitly specify them.
Differential Revision: https://phabricator.services.mozilla.com/D3728
--HG--
extra : rebase_source : b708f382d8ea571d199c669bfed5b5a7ca9ffac4
extra : histedit_source : 7df6feb82088c8a5ca45dc28fe4d2b852c177fee
Since Windows doesn't provide native thin scrollbar variant, this patch
tries to synthesize one by doing the following:
* force to use custom scrollbar, and
* hide the scrollbar button by giving them zero size, and
* cut the thickness of scrollbar by half.
Half thickness is picked randomly, but it seems to work fine. A third
of the size also looks fine, but maybe a bit harder to drag.
Note: Universal Windows Platform apps seem to have an overlay style of
scrollbar by default, but I cannot find any Windows API to render that,
so that may be a builtin component of UWP. We may want to do that at
some point, but this is probably good enough for now.
MozReview-Commit-ID: KfHjy8WdweT
--HG--
extra : rebase_source : 4776fc5e2264c0b9146ca89d40b4e8b952307d0e
So that we can use custom scrollbar for thin scrollbar.
MozReview-Commit-ID: FCHzV5MJbx
--HG--
extra : rebase_source : 4742d2bb1f612ff60890d5c01a4532ee4542624e
Now nsBaseWidget::NotifyThemeChanged properly notifies to the pres shell.
MozReview-Commit-ID: Kmd68ckHanl
--HG--
extra : rebase_source : 9928f3788f34b05ff91d1d2b11e2cd332f00af76
This introduces the machinery needed to generate crash annotations from a YAML
file. The relevant C++ functions are updated to take a typed enum. JavaScript
calls are unaffected but they will throw if the string argument does not
correspond to one of the known entries in the C++ enum. The existing whitelists
and blacklists of annotations are also generated from the YAML file and all
duplicate code related to them has been consolidated. Once written out to the
.extra file the annotations are converted in string form and are no different
than the existing ones.
All existing annotations have been included in the list (and some obsolete ones
have been removed) and all call sites have been updated including tests where
appropriate.
--HG--
extra : source : 4f6c43f2830701ec5552e08e3f1b06fe6d045860
ATOK 2016 and newer may show candidate window at odd position temporarily
when user converts a word quickly (e.g., keep pressing space bar).
For avoiding this flicker, we should keep hacking GetTextExt() result for
ATOK 2016 and later even after Windows fixes TS_E_NOLAYOUT bug.
We should get feedback from each CJKT testers at least one cycle after Win10
RS5 is released. Until then, we should not stop hacking GetTextExt() result
in late Beta nor Release builds.
Microsoft Pinyin and Microsoft Wubi (Simplified Chinese TIPs) work better on
Windows 10 Build 17643 or later (i.e., TS_E_NOLAYOUT bug is fixed). However,
they sometimes do not show candidate window, perhaps, the reason is something
stateful bug in them. Therefore, we still need to hack the result of
GetTextExt() until they fix this bug.
Currently, TSFTextStore::MaybeHackNoErrorLayoutBugs() checks pref to enable
hack first, then, check if active TIP is the target of pref. This was intended
to save comparison cost of GUIDs. However, we don't need to worry about the
cost and that was not makes sense since all prefs are true by default.
So, this patch makes the big if-elseif blocks with switch-case with
TSFStaticSink::ActiveTIP(). Then, each case block starts to check if
- if Windows still TS_E_NOLAYOUT bug of GetTextExt().
- if corresponding pref is true.
Note that this duplicates some code for making the code look easier.
E.g., eMicrosoftOfficeIME2010ForJapanese case is duplicated from
the eMicrosoftIMEForJapanese case. eMicrosoftPinyin and eMicrosoftWubi case
is duplicated from the eMicrosoftChangJie and eMicrosoftQuick case.
As we know, GUID comparison is not cheap if it's required a lot. Unfortunately,
we need to check it more in TSFTextStore::MaybeHackNoErrorLayoutBugs() and
it's called a lot. So, even though mapping from GUID to TIP is expensive,
we should do it only once. Note that most users won't change IME during a
browser session, so, running this expensive method once must be reasonable.
On the other hand, we don't allow to make damage to start up performance,
we should avoid to do it as far as possible. For example, when we need to
check if active TIP is a specific TIP, we should check current language.
It doesn't appear these IDL files have had interfaces in them since
before the Netscape import, and were mostly just hanging around
because they contained some IDs needed elsewhere. Move the IDs
somewhere more appropriate and remove files.
MozReview-Commit-ID: AINtTerqHu1
Differential Revision: https://phabricator.services.mozilla.com/D2688
--HG--
extra : moz-landing-system : lando
At Windows 10 build 17643, Microsoft fixed the bug of TSF which returns E_FAIL
to TIP when GetTextExt() returns TS_E_NOLAYOUT. With this fix, most TIPs do
not have any problems even if we return TS_E_NOLAYOUT. So, unless active
TIP still needs the hack, the method can skip the hack if running on build
17643 or later.
Note that we still need to support Japanist 10 and Microsoft Office IME 2010.
It confirmed that Japanist 10 has a bug of handling TS_E_NOLAYOUT. On the
other hand, we have not tested Microsoft Office IME 2010 since it's installable
only into Win7 or Win8 and needs to upgrade it to Win10 for testing, but I
do not have the license. After the fix comes into release channel, I'll be
able to test it though (my main environment is Win10 and it was installed
before upgraded). So, we need to be back after Microsoft releases the fix.
MozReview-Commit-ID: 2BzkDvHTKyI
--HG--
extra : rebase_source : ee0261c83c5a1ab7b2aa2a8f476f0c6634e2cf34
The block in TSFTextStore::GetTextExt() which decides whether we should return
S_OK with unmodified character rectangle rather than TS_E_NOLAYOUT is too big.
Additionally, we need to add new condition to check Windows 10's version there.
That makes the large block more complicated. So, we should split the block
off from TSFTextStore::GetTextExt(). Then, we can use early-return-style to
reduce the deep indentations.
MozReview-Commit-ID: J2BJMB1QD0T
--HG--
extra : rebase_source : 3c86b5ed3a83fda1045a6453250e784f11419b97
The '-moz-menulist-button' value currently behavies identically to the
'menulist-button' value. This is not implemented as an alias because later
patches in this patch series will change the behavior of our pre-existing
'menulist-button' value to more closely match what Chrome does.
The '-moz-menulist-button' value currently behavies identically to the
'menulist-button' value. This is not implemented as an alias because later
patches in this patch series will change the behavior of our pre-existing
'menulist-button' value to more closely match what Chrome does.
--HG--
extra : rebase_source : b66bf6427db5be2eb12f4e0aa36d22a4da46555a
The constructor of WidgetCommandEvent takes 2 nsAtom pointers. One is for
specifying event type, the other is for specifying the command. The
difference of these arguments are pretty unclear for other developers and
the former argument is always nsGkAtoms::onAppCommand unless nullptr in
C++ code. So, we can hide the former argument.
Then, we should create another constructor for creating empty command event
from constructor of dom::CommandEvent.
Differential Revision: https://phabricator.services.mozilla.com/D2506
--HG--
extra : moz-landing-system : lando
The patch at bug 1478391 comment 6 changed the way the math in Scrollbarbutton*
worked, which pretty surely caused this.
Restore the original order and math to be the same as before bug 1478391.
MozReview-Commit-ID: CK3iOqeX2NW
Even with this patch, the setting change doesn't affect media queries in sub
frames due to bug 1478212. But the bug is a pre-existing issue, for example
system color settings don't affect contents in sub frames either. So we can
land this patch as it is.
Note that there is no way to write an automation test for this unfortunately.
MozReview-Commit-ID: L2Knhp1IjrU
--HG--
extra : rebase_source : 3487a13d0466b68419e55610c8ce3e384df28e64
This builds on bug 1428676 and introduces StyleAppearance, which replaces the
NS_THEME_* constants.
Really sorry for the size of the patch.
There's a non-trivial change in the gtk theme, which I submitted separately as
bug 1478385.
Differential Revision: https://phabricator.services.mozilla.com/D2361
MozReview-Commit-ID: DiSmMWK7Krp
widget/windows/WinUtils.h is getting unwieldy and contains a combination of
both header-only and non-header-only code. I thought I'd take the opportunity
with this patch to create a new file for self-contained, header-only utility
functions, with the hope that we can eventually migrate some stuff out of
WinUtils into WinHeaderOnlyUtils in the future.
--HG--
extra : rebase_source : 6c874f78fc7113d1f7011fcd57ad9d024edb6761
I mistranslated the boolean success value of the old initListBuild
method. Simplifying it to just use a promise rejection should be
equivalent and simpler, since this is only run from the update
method of WindowsJumpLists, and the call sites for that don't do
anything afterwards.
Differential Revision: https://phabricator.services.mozilla.com/D2244
--HG--
extra : moz-landing-system : lando
This removes an unused gfxConfig check and changes Maybe<FeatureStatus>
into FeatureStatus as none of the callers were using None.
MozReview-Commit-ID: Kep6nYpDI3B
--HG--
extra : rebase_source : d7f71dd9b358bfd2c57380d7bc194d6002a50cb9
I initially tried to avoid this, but decided it was necessary given the number
of times I had to repeat the same pattern of casting a variable to void*, and
then casting it back in a part of code far distant from the original type.
This changes our preference callback registration functions to match the type
of the callback's closure argument to the actual type of the closure pointer
passed, and then casting it to the type of our generic callback function. This
ensures that the callback function always gets an argument of the type it's
actually expecting without adding any additional runtime memory or
QueryInterface overhead for tracking it.
MozReview-Commit-ID: 9tLKBe10ddP
--HG--
extra : rebase_source : 7524fa8dcd5585f5a31fdeb37d95714f1bb94922
We're already committing jump lists on mIOThread, and I see
no errors or problems with initting on mIOThread either, so
I think this is okay. Had to restructure some things to
make using a Promise simple, and to avoid dispatching to
mIOThread from within mIOThread (since we can only dispatch
to a LazyIdleThread from the owner thread).
MozReview-Commit-ID: 1imBF8Jzmn6
--HG--
extra : rebase_source : 4f912e819cec898910e72d95311e3924714a3090
When user removes all composition string of MS Pinyin, MS Wubi, MS ChangJie and
MS Quick with Backspace key, IME commits last character temporarily and
restart composition to replace the last character with empty string when
user tries to remove last one character.
This causes flicking composition string because the additional composition
selects the character and it may be painted immediately before removed, and
also editor will have unnecessary undo transaction.
Therefore, as same as bug 1208043, TSFTextStore::RecordCompositionStartAction()
should restart last composition in such case. Fortunately, we implemented
similar code for bug 1208043, however, unfortunately, we don't have preceding
pending compositionstart in this case. Therefore, this patch makes
pending compositionend store start offset of composition. Then, we can
restart composition only with information stored by pending compositionend
action. Additionally, this patch renames the method checking pending
actions for self-describing the new meaning.
MozReview-Commit-ID: 1RyuacxEbky
--HG--
extra : rebase_source : 1c8ecc0b63114ae65c77cd76cb85a21d2716442c
Some odd mouse drivers try to activate a window which the mouse driver wants to
scroll its content (such window is typically under the mouse cursor when mouse
wheel is turned). However, this is illegal behavior and such odd mouse drivers
try to activate our popup windows which won't be activated without such apps.
We prevented this odd focus behavior with fixing of bug 953146. However, it
did NOT stop notifying widget listener of activating nor inactivating the
windows. Therefore, that caused a lot of reflow for supporting
-moz-window-inactive pseudo class.
This patch makes nsWindow::DealWithPopups() consume WM_ACTIVATE message before
nsWindow::ProcessMessage() because nsWindow::ProcessMessage() notifies widget
listener of activating and inactivating window even when focus move from and to
our popup window. So, in other words, this patch stops notifying widget
listener of activating and inactivating window when focus moves from/to
a popup window.
MozReview-Commit-ID: 2dyq07zHZKp
--HG--
extra : rebase_source : 8075a3ead73a5f2892a1a1a8e71252e574200bf4
Currently, if an event is consumed in the main process, EventStateManager
does not send it to remote process. However, this is unexpected behavior
for some WidgetKeyboardEvent dispatchers. OS sometimes has consumed native
key events before sending applications. For example, Alt key on Windows
should activate menu bar of focused window but Alt key may be consumed before
focused window receives the event. In such case, we mark Alt keyboard event
as "consumed before dispatch", and chrome treat it like as its preventDefault()
is called in web content. (Note that for compatibility with other browsers,
the consumed state is not exposed to web content. So, Event.defaultPrevented
returns false in web content.)
Therefore, we need to treat "consumed" state and "cross process forwarding"
state separately. This patch makes calling WidgetEvent::PreventDefault()
always stops cross process forwarding for backward compatibility. Additionally,
for the special case mentioned above, this patch makes
WidgetEvent::PreventDefaultBeforeDispatch() take additional argument,
|aIfStopCrossProcessForwarding|. If this is CrossProcessForwarding::eStop,
the event won't be sent to remote process as same as calling PreventDefault().
Otherwise, CrossProcessForwarding::eHold, PreventDefaultBeforeDispatch() call
does not change "cross process forwarding" state. I.e., if the event's
StopCrossProcessForwarding() and PreventDefault() are not called until
EventStateManager::PostHandleEvent(), the event will be sent to remote process
as usual.
MozReview-Commit-ID: IQGWJvXetxV
--HG--
extra : rebase_source : 4ccdd500e80b8fe29e469ac3b85578e1c07c8358
We always struggle with a lot of IME bugs on Windows. Currently, any IME
vendors should've already released TIP for TSF rather than legacy IMM-IME
since IMM-IME is not available on UWP apps. Additionally, due to API
limitation, it's difficult to get human-friendly name of IMM-IME. So, let's
collect only TIP names of TSF on Windows. This must be enough.
Note that we cannot get common-English name even though the API to retrieve
TIP name taking language code. Therefore, a TIP may be collected with
different name, e.g., one is Japanese name and the other is English name.
If we collect GUIDs of TIP, we can avoid this issue. However, it's
difficult to collect both GUID and human-friendly name since Telemetry
key is up to 72 characters.
Currently, I give up to avoid this duplicated issue. Perhaps, this is not
so serious issue since most TIP users must match language of TIP and their
system language settings. Therefore, this patch collects Locale ID of
TIP and description of it. Locale ID is necessary because some TIPs may be
named same name for different languages. For example, both Japanese and
Hangul IMEs of Microsoft are named as "Microsoft IME".
MozReview-Commit-ID: IeSxfeqS62a
--HG--
extra : rebase_source : b269ce3c41f7a998193972afb31183a61d3948be
Cosmin Sabou
Emilio Cobos Álvarez
Masayuki Nakano
Razvan Maries
Alex Gaynor
Jim Mathies
Sylvestre Ledru
Masatoshi Kimura
Gurzau Raul
Bogdan Tara
meandave
Mike Conley
Andrew Comminos
Dorel Luca
David Major
Andrea Marchesini
Ciure Andrei
Adam Gashlin
Carl Corcoran
Felipe Gomes
Ryan Hunt
Jonathan Kingston
Tarek Ziadé
Jeff Muizelaar
Jeff Walden
Kris Maglione
arthur.iakab
Andrew Osmond
Daniel Varga
Mike Hommey
Aaron Klotz
Jorg K
sotaro
Csoregi Natalia
Edgar Chen
Bob Owen
Ehsan Akhgari
Dragana Damjanovic
Coroiu Cristina
Thomas Nguyen
Xidorn Quan
Barret Rennie
Dzmitry Malyshau
Tom Schuster
Makoto Kato
Florian Quèze
Tooru Fujisawa
Andreea Pavel
Gabriele Svelto
Mats Palmgren
Narcis Beleuzu
Brindusan Cristian
Boris Zbarsky
Jonathan Watt
Lee Salzman
Daosheng Mu
Kartikaya Gupta
shindli
Jeff Gilbert
Dale Harvey
Hiroyuki Ikezoe
Jean-Yves Avenard
Neil Deakin
Noemi Erli
Andrew McCreight
Neil Deakin
Edouard Oger
Bas Schouten
Thomas Wisniewski
Gijs Kruitbosch
Paolo Amadini
Nicholas Nethercote
Kyle Machulis
Jan de Mooij
Doug Thayer
Jeff Muizelaar
Margareta Eliza Balazs
Dão Gottwald
Matt Howell