This only hides the cursor if it's on the page you're editing, but given
that the point of the feature is to move the cursor out of the way, that
seems acceptable (and honestly it feels more of a feature than a bug).
This should work across platforms (though non-windows platforms need
ui.hideCursorWhileTyping=1 in about:config to enable).
Differential Revision: https://phabricator.services.mozilla.com/D171155
If we enter `SpinEventLoopUntil` while certain Windows events are
waiting for resolution, we may enter an unusable state.
Since removing all `SpinEventLoopUntil` instances -- or even the one
causing this problem -- isn't really an option at present, kick the can
down the road by kicking the can down the road [sic].
Differential Revision: https://phabricator.services.mozilla.com/D185969
Remove calls to `IsWin10OrLater()`.
The Windows 7 taskbar does not have this particular race condition, so
there is no need to perform it there. As Firefox no longer supports
Windows 7, there is no need for these checks in Nightly; they existed
solely to simplify uplift of that commit to ESR (which _does_ still
support Win7).
Differential Revision: https://phabricator.services.mozilla.com/D184774
To work around a race condition involving unminimizing windows, post a
message to our own message queue, to notify the taskbar that fullscreen
state recalculation is potentially necessary. (This notification must
occur _after_ we have finished processing the `WM_WINDOWPOSCHANGING`
message.)
Differential Revision: https://phabricator.services.mozilla.com/D184762
Some basic clean-up. I want to do this before doing bigger changes in
bug 1843044.
There's tons more code that can get cleaned-up on the widget side, but
let's start with this.
Differential Revision: https://phabricator.services.mozilla.com/D183622
Just like we rollup menus.
This is needed because tooltips otherwise get hidden on mousedown and
don't flush the view manager.
This matches the similar hunk for GTK in bug 1569439.
Differential Revision: https://phabricator.services.mozilla.com/D183489
The window message we previously hooked no longer gets sent and the associated shared memory no longer seems to be created either.
Also, we don't seem to be notified about the load of UIAutomationCore.dll until after it has already instantiated a11y, which is obviously too late for us to hook anything.
Instead, we block UIA instantiation via LazyInstantiator, just as we do for MSAA/IA2:
1. Refactor CompatibilityUIA so that rather than being called by a hook, it simply allows the caller to query the process ids of any UIA clients.
2. CompatibilityUIA now searches handles in our process for named pipes created by UIA for communication with the remote process and then uses GetNamedPipeServerProcessId to get the process id on the other end of each pipe.
3. Refactor LazyInstantiator so that it first tries to get the MSAA/IA2 client process id, then calls CompatibilityUIA to get any UIA client process ids.
4. LazyInstantiator now handles setting the instantiator and blocking of clients for UIA as well as MSAA/IA2 using the same code.
5. Because UIA client detection can be expensive if clients repeatedly query us, cache the result. Reset that cache only when one of our windows comes to the foreground.
Differential Revision: https://phabricator.services.mozilla.com/D181958
The window message we previously hooked no longer gets sent and the associated shared memory no longer seems to be created either.
Also, we don't seem to be notified about the load of UIAutomationCore.dll until after it has already instantiated a11y, which is obviously too late for us to hook anything.
Instead, we block UIA instantiation via LazyInstantiator, just as we do for MSAA/IA2:
1. Refactor CompatibilityUIA so that rather than being called by a hook, it simply allows the caller to query the process ids of any UIA clients.
2. CompatibilityUIA now searches handles in our process for named pipes created by UIA for communication with the remote process and then uses GetNamedPipeServerProcessId to get the process id on the other end of each pipe.
3. Refactor LazyInstantiator so that it first tries to get the MSAA/IA2 client process id, then calls CompatibilityUIA to get any UIA client process ids.
4. LazyInstantiator now handles setting the instantiator and blocking of clients for UIA as well as MSAA/IA2 using the same code.
5. Because UIA client detection can be expensive if clients repeatedly query us, cache the result. Reset that cache only when one of our windows comes to the foreground.
Differential Revision: https://phabricator.services.mozilla.com/D181958
Bug 1704954 disabled DirectComposition for users with NVIDIA graphics
hardware and mixed monitor refresh rates on Windows 10 and 11, as a
mitigation for bug 1638709. However, that bug is almost -- perhaps
entirely -- unknown on Windows 11 (q.v. for details), and the fallback
path it uses has been shown to cause issues there (bug 1763981).
Restrict the mitigation to only occur on Windows 10, where bug 1638709
is exhibited, but where no issues with the fallback path are known.
This also effectively reverts bug 1816001, which it obviates.
Differential Revision: https://phabricator.services.mozilla.com/D178848
Tentative patch, as I don't have win7 to test.
We handle input region in WM_NCHITTEST, I don't see why we need to
change the window style...
Differential Revision: https://phabricator.services.mozilla.com/D178097
If we rollup with animations but get occluded right away, we might not
advance the refresh driver enough for the animation to finish.
Tentative patch, as I wasn't able to reproduce this... But we've seen
similar issues in other OSes, see bug 1810797.
Differential Revision: https://phabricator.services.mozilla.com/D177934
That's a rather obscure side effect, which causes the window not to be
recognized as toplevel in some tools.
Other platforms don't have such weirdness. You can still create windows
with WindowType::Popup for that.
Note: We also remove the WS_CHILD bit, which is there just because the
documentation mentions that it's exclusive with WS_POPUP, but I don't
think anything sets that bit earlier, so it's a no-op.
Differential Revision: https://phabricator.services.mozilla.com/D177673
Remove `nsIWidget::SetNativeData()` and all implementations thereof, as
none of them have had any functionality or use since bug 1338172.
No functional changes.
Differential Revision: https://phabricator.services.mozilla.com/D177568
Rather than having `nsWindow::GetNativeData()` sometimes (argument-
dependently) create a new resource and requiring its various callers to
destroy that resource, consolidate its creation and destruction into a
single external class.
No functional changes.
Differential Revision: https://phabricator.services.mozilla.com/D177567
DWM doesn't update its cached nonclient region information when a window
changes its client area without changing its actual size.
This happens in Firefox when a maximized window becomes fullscreen. If
this happens, "flicker-resize" the window to force DWM to update.
Differential Revision: https://phabricator.services.mozilla.com/D176844
Remove unused code:
- nsWindow::AutoErase() (allegedly overridable but nonvirtual function)
- nsWindow::mIsPainting (flag which is never set)
... and perform a very minor comment emendation, for clarity.
Differential Revision: https://phabricator.services.mozilla.com/D176842
DWM doesn't update its cached nonclient region information when a window
changes its client area without changing its actual size.
This happens in Firefox when a maximized window becomes fullscreen. If
this happens, "flicker-resize" the window to force DWM to update.
Differential Revision: https://phabricator.services.mozilla.com/D176844
Remove unused code:
- nsWindow::AutoErase() (allegedly overridable but nonvirtual function)
- nsWindow::mIsPainting (flag which is never set)
... and perform a very minor comment emendation, for clarity.
Depends on D176841
Differential Revision: https://phabricator.services.mozilla.com/D176842
The unpainted non-client region leaves a white bar at the bottom of the window when maximized on Win11 with auto-hidden taskbar. This region is where a user can mouse-over to expose the taskbar. Painting it black eliminates the row of white pixels and fixes problems with exposing the hidden taskbar. Windows 10 usually (correctly) paints a sliver of the taskbar in this region with or without this patch. However, it also has similar (but more complex) failing edge cases discussed in the bug.
Additionally, bug 758280 used 1px for the autohidden region size but the real size is 2px so we switch to that here.
Differential Revision: https://phabricator.services.mozilla.com/D148834
Since Windows 8, ABM_GETAUTOHIDEBAREX has provided a way to identify if/where the system taskbar is hidden, even in multi-monitor setups. This adds a function to easily fetch that information.
Differential Revision: https://phabricator.services.mozilla.com/D148833
The unpainted non-client region leaves a white bar at the bottom of the window when maximized on Win11 with auto-hidden taskbar. This region is where a user can mouse-over to expose the taskbar. Painting it black eliminates the row of white pixels and fixes problems with exposing the hidden taskbar. Windows 10 usually (correctly) paints a sliver of the taskbar in this region with or without this patch. However, it also has similar (but more complex) failing edge cases discussed in the bug.
Additionally, bug 758280 used 1px for the autohidden region size but the real size is 2px so we switch to that here.
Differential Revision: https://phabricator.services.mozilla.com/D148834
Since Windows 8, ABM_GETAUTOHIDEBAREX has provided a way to identify if/where the system taskbar is hidden, even in multi-monitor setups. This adds a function to easily fetch that information.
Differential Revision: https://phabricator.services.mozilla.com/D148833
It is not clear why checking sCanQuit here should be the right thing to
do. From the WM_ENDSESSION documentation it seems there are cases where
we just need to quit, always. Windows might even have ignored the
WM_QUERYENDSESSION result or sCanQuit might be unset if we did not pass
through WM_QUERYENDSESSION at all.
Differential Revision: https://phabricator.services.mozilla.com/D175244
This patch adds two new attributes to the window's `html` element, `windowclass` and `windowname`, to allow directly controlling the window's class hints on Xorg/Wayland (`res_class` and `res_name`) from the chrome/JS code. When they are set, values are used as class hints for their window. When they are not set, the current behavior of determining `res_class` and `res_name` (using `gdk_get_program_class` for `res_class` and parsing `windowtype` for `res_name`) is preserved.
Changes in `widget/nsIWidget.h` and `widget/nsBaseWidget.h` are only interface changes so that `setWindowClass` can accept three attributes. Although this patch does not affect Windows, `widget/windows/nsWindow.h` and `widget/windows/nsWindow.cpp` have been updated to comply with the new interface. `xpfe/appshell/AppWindow.cpp` has been updated to get the additional attributes and call `setWindowClass` with them. The main changes are in `widget/gtk/nsWindow.h` and `widget/gtk/nsWindow.cpp`.
Differential Revision: https://phabricator.services.mozilla.com/D169720
Emilio Cobos Álvarez
Ray Kraesig
Masatoshi Kimura
Tooru Fujisawa
Natalia Csoregi
James Teh
Iulian Moraru
Aidan Welch
Edgar Chen
David Parks
Stanca Serban
Butkovits Atila
Norisz Fay
Jens Stutte
filips
Florian Quèze