This patch does not make some header files stop including the inline
header because fixing them require more changes.
Note that `#include "nsComponentManagerUtils.h"` is fixing a bustage
caused by "use of undeclared identifier 'do_CreateInstance'" error.
Differential Revision: https://phabricator.services.mozilla.com/D304432
This reverts commit 312ba34b1e.
Revert "Bug 2039903 - Use nsIWidget::NativeModifiers for SynthesizeNativeKeyEvent. r=masayuki,win-reviewers,gstoll"
This reverts commit cdcd922a07.
Revert "Bug 2039903 - Use proper types for PBrowser::SynthesizeNativeMouseEvent. r=masayuki"
This reverts commit 45369938ed.
Revert "Bug 2039903 - Change from nsIWidget::Modifiers to nsIWidget::NativeModifiers. r=masayuki,geckoview-reviewers,win-reviewers,m_kato,gstoll"
This reverts commit 479f174ddb.
It seems it's no longer needed, and it might cause issues with
third-party software. Since we're at the beginning of the cycle it
probably makes sense to try this.
Differential Revision: https://phabricator.services.mozilla.com/D301499
First, while `IMMHandler` handles a composition, it should store the
composing window with a strong pointer because it's required to
clean up the resource before its destroyed.
Then, if the window is destroyed during a composition, `IMMHandler`
should clear the strong pointer with canceling the composition.
This should be done during the emulation of `blur` in
`IMEHandler::OnDestroyWindow()`. However, now, it's called after the
window handle is destroyed [1] and fails to clean up some things, e.g.,
in `IMEHandler::SetInputScopeForIMM32()` [2]. Therefore,
`nsWindow::OnDestroy()` and `nsWindow::Destroy()` call
`IMEHandler::OnDestroyWindow()` before destroying the native window.
Finally, to avoid the race condition of the destruction and the focus
move, `IMEHandler::OnDestroyWindow()` notifies `IMMHandler` of that
for ensuring the clean up.
1. https://searchfox.org/firefox-main/rev/f98aa512e7b7d557ec2d57dbf67b0c4285e9cd3a/widget/windows/nsWindow.cpp#1327,1334
2. https://searchfox.org/firefox-main/rev/f98aa512e7b7d557ec2d57dbf67b0c4285e9cd3a/widget/windows/WinIMEHandler.cpp#542-543,561-562
Differential Revision: https://phabricator.services.mozilla.com/D296902
SetWindowsHookEx(WH_GETMESSAGE) requires an interactive window station.
CI/automation environments (e.g. Windows service accounts, restricted desktop
sessions) may run Firefox without one, causing SetWindowsHookEx to return NULL.
The MOZ_ASSERT(mHook) was added in 2017 when this code was guarded by
interactive-desktop builds where touch input exists. Bug 1330460 (same year)
removed the _M_IX86 guard and broadened the code to all architectures without
revisiting the assert, leaving a latent crash in any non-interactive build.
This latent crash surfaces in the WMFClearKey mochitests added in Part 7 of
this series: Windows CI machines run the test process without an interactive
window station, which causes SetWindowsHookEx to return NULL and trigger the
assert. When the hook fails to register, the TIPHook callback never fires,
so mA11yBlockCount stays 0 and IsA11yBlocked() always returns false. Touch and
tablet a11y blocking is simply inactive, which is harmless in environments
without touch input. The destructor already null-checks mHook before calling
UnhookWindowsHookEx. Downgrading to NS_WARNING_ASSERTION is the correct fix.
Differential Revision: https://phabricator.services.mozilla.com/D293606
And remove unused includes of nsGkAtoms.h in the process. The few
dependencies have been moved to ServoStyleConstsInlines.h
The used command to remove the now unused dependency was:
git grep -l nsGkAtoms.h | while read line; do grep -v nsGkAtoms.h $line | grep -q -E '\<nsGkAtoms\>' || sed -i -e '/nsGkAtoms.h/d' $line ; done
Differential Revision: https://phabricator.services.mozilla.com/D292697
And remove unused includes of nsGkAtoms.h in the process. The few
dependencies have been moved to ServoStyleConstsInlines.h
The used command to remove the now unused dependency was:
git grep -l nsGkAtoms.h | while read line; do grep -v nsGkAtoms.h $line | grep -q -E '\<nsGkAtoms\>' || sed -i -e '/nsGkAtoms.h/d' $line ; done
Differential Revision: https://phabricator.services.mozilla.com/D292697
Even after this fix you can still see a brief flash of the "regular"
titlebar, but it's waaaay less jarring because the colors match.
Differential Revision: https://phabricator.services.mozilla.com/D280074
Update usage of nsWinGesture::UpdatePanFeedback[XY] to take a boolean for
scrollOverflow, removing the need to take absolute value.
Take advantage of GetSystemMetrics(SM_C[XY]DOUBLECLK) returning an
unsigned value to replace usage of DeprecatedAbs by Abs.
Differential Revision: https://phabricator.services.mozilla.com/D279636
We don't rely on DWM buttons + custom non-client area in any
configuration nowadays (this used to be the case with windows 7).
Differential Revision: https://phabricator.services.mozilla.com/D274417
We only need to grab its AppWindow for that to happen. Save some useless
QI while at it.
I'm pretty sure bug 2002986 would also help here but this seems worth
doing regardless.
Differential Revision: https://phabricator.services.mozilla.com/D274419
See the comment for reasoning. WM_NCCALCSIZE wasn't getting called, and
we rely on that to get the right client area on things like maximized
windows.
Differential Revision: https://phabricator.services.mozilla.com/D274281
When a window with WS_BORDER is maximized on a low-ish DPI monitor, an
"extra" border on top shows up. This breaks the workflow of moving your
mouse to the very top of the screen to hover over or select tabs.
(people have reported this with non-Firefox apps so I'm guessing this is
really an OS problem)
But the WS_BORDER style doesn't actually seem necessary for us when tabs
are being shown in the toolbar - removing it still means we can resize
our window, etc.
We do need to handle the case when tabs are not being shown in the toolbar,
so we have to toggle the WS_BORDER style when that changes. I tested on my
system in a number of different configurations and it seems to work fine.
I believe this will fix bug 1994918 and possibly some others.
Differential Revision: https://phabricator.services.mozilla.com/D272653
Masayuki Nakano