See bug for justification. This patch aims to display a blank window prior to
loading/prefetching xul.dll. It also has a placeholder for drawing a
skeleton UI into that window. Note that this is disabled by default based on
a registry value, as there are still kinks to work out (for instance, what
happens if we aren't actually going to display a window, because, say, Firefox
is already running.) This just gives a basic implementation to dogfood, and
facilitates distributing work across multiple contributors.
Onto the details. The patch achieves its goal by creating a window and
assigning its handle to a static variable, which will be consumed inside
nsWindow::Create by the first toplevel window we want to make. nsWindow::Create
will take ownership of the window handle, restyle it to its own liking, and
then proceed as if everything is normal and it had created the window itself.
Differential Revision: https://phabricator.services.mozilla.com/D86263
See bug for justification. This patch aims to display a blank window prior to
loading/prefetching xul.dll. It also has a placeholder for drawing a
skeleton UI into that window. Note that this is disabled by default based on
a registry value, as there are still kinks to work out (for instance, what
happens if we aren't actually going to display a window, because, say, Firefox
is already running.) This just gives a basic implementation to dogfood, and
facilitates distributing work across multiple contributors.
Onto the details. The patch achieves its goal by creating a window and
assigning its handle to a static variable, which will be consumed inside
nsWindow::Create by the first toplevel window we want to make. nsWindow::Create
will take ownership of the window handle, restyle it to its own liking, and
then proceed as if everything is normal and it had created the window itself.
Differential Revision: https://phabricator.services.mozilla.com/D86263
See bug for justification. This patch aims to display a blank window prior to
loading/prefetching xul.dll. It also has a placeholder for drawing a
skeleton UI into that window. Note that this is disabled by default based on
a registry value, as there are still kinks to work out (for instance, what
happens if we aren't actually going to display a window, because, say, Firefox
is already running.) This just gives a basic implementation to dogfood, and
facilitates distributing work across multiple contributors.
Onto the details. The patch achieves its goal by creating a window and
assigning its handle to a static variable, which will be consumed inside
nsWindow::Create by the first toplevel window we want to make. nsWindow::Create
will take ownership of the window handle, restyle it to its own liking, and
then proceed as if everything is normal and it had created the window itself.
Differential Revision: https://phabricator.services.mozilla.com/D86263
The existing rollup-handling code in SendAnAPZEvent was mostly copied from
the DealWithPopups function, so this patch removes that duplication and reuses
the existing codepath. And it adds some extra checking for dmanip events that
mirrors the checking we do for other events, so that events that are targeted
inside the popup don't cause the popup to get rolled up.
Differential Revision: https://phabricator.services.mozilla.com/D86603
This allows us to reuse this function and the GetPopupsToRollup function when
an event point is different than what comes out of GetMessagePos.
For instance, the WM_POINTERDOWN code can now reuse this functions properly.
This fixes a latent bug where it was calling GetPopupsToRollup which was using
an possibly-incorrect point internally.
Differential Revision: https://phabricator.services.mozilla.com/D86754
Otherwise when we try to call Deactivate on the direct manipulation manager (to balance the Activate call) we won't have the HWND pointer and so it won't balance and we will leak.
We call DestroyDirectManipulation in nsWindow::Destroy but it looks like nsWindow::OnDestroy can be called before nsWindow::Destroy.
Differential Revision: https://phabricator.services.mozilla.com/D85835
Currently `nsWindow::UpdateNonClientMargins()` calls DPI-unaware `GetSystemMetrics()` to get the window frame sizes and `nsWindow::ProcessMessage()` simply multiplies them by the screen scale ratio. This is wrong as the frame sizes do not increase in linear scale (8 in 100% scale while 13 in 200% scale). This patch uses DPI-aware `GetSystemMetricsForDpi()` to correct this.
Differential Revision: https://phabricator.services.mozilla.com/D81447
SPI_GETFLATMENU uses the newly-added WinContentSystemParameters and adds
the ability to update theme-related variables when they change.
Differential Revision: https://phabricator.services.mozilla.com/D80071
To enable Win32k lockdown, calls involving native theme will need to be
removed.
Currently these calls are scattered around several files. This class creates
a proxy for the Win32 calls. Whitelisting this class in awcw32ks makes it much
easier to track Win32k removal with themes removed.
As an added benefit, once non-native theming is done it will be easy to verify
by asserting that this class is never created in Content.
Differential Revision: https://phabricator.services.mozilla.com/D75946
The current notification enumerates all windows and calls
SysColorChanged on them.
The current implementation of SysColorChanged is not quite sound, as it
really needs most if not all of what ThemeChanged does: SVGs can use
system colors, so we need to also invalidate the image cache for
example.
It's also not clear it deals correctly with propagating system color
changes to other documents.
In some cases we were even firing both theme changes and system color
changes at the same time. Unify this code paths.
Differential Revision: https://phabricator.services.mozilla.com/D76487
When window is PiP window on Windows7, WS_EX_COMPOSITED is set to suppress flickering during resizing with hardware acceleration as a workaround.
PiP window detection in nsAppShellService::JustCreateTopWindow() mimics Linux/Gtk implementation.
Differential Revision: https://phabricator.services.mozilla.com/D77663
The enforcement is only important when users are able to resize the windows. Otherwise,
we let Gecko set the window dimensions to whatever dimensions they'd like.
Differential Revision: https://phabricator.services.mozilla.com/D78538
On other platforms we get a mousedown event when the non-client area is clicked,
but not on Windows, where handling the WM_NCLBUTTONDOWN message breaks dragging
the window. This dispatches the mousedown event like other platforms, but on
the next tick.
Differential Revision: https://phabricator.services.mozilla.com/D77419
When we call nsWindow::Show but Firefox is not foreground, we show the window
and also flash it on the taskbar to get the user's attention.
This is really annoying when restoring a session with `N` windows, as the
user's taskbar ends up with all `N` of them stuck in a flashed state until the
user goes through and manually activates every single window.
There are several ways I thought of to address this, but I think the
simplest one is just to track whether or not we're in the middle of restoring a
session and skip flashing when we are doing so.
Differential Revision: https://phabricator.services.mozilla.com/D76406
Direct Manipulation uses a different input model from processing messages that Windows sends.
Windows asks us if we want to start a direct manipulation session by sending us the DM_POINTERHITTEST message, and we call SetContact if we do. After that Windows won't send us messages until the user ends the gesture. Instead Direct Manipulation will update a transform (that's invisible to the user). We pull that transform and turn it into pan and pinch gestures.
So DealWithPopups is not called and popups don't get rolled up. Instead I call it in the function where we send all events that come from dmanip.
Differential Revision: https://phabricator.services.mozilla.com/D74215
The old code didn't handle content prevent defaulting the input.
The pinch gesture code doesn't seem to fully work properly, it will allow a little pinch zooming before halting it if content is prevent defaulting it. Not sure what is up yet.
Differential Revision: https://phabricator.services.mozilla.com/D73220
We can't just get pinch events, we need to handle both.
This state machine code is basically copied from Chrome's implementation.
Differential Revision: https://phabricator.services.mozilla.com/D71307
The only caveat here is that gfxVars are not atomic, but multiple threads can
query DWM status. To solve this, changes to the var are mirrored into an atomic
and that is read instead.
DWM status changes are indicated by Windows via a window message. We use that
window message to cause the update to propagate
Differential Revision: https://phabricator.services.mozilla.com/D73743
Currently, There are multiple places that call the Win32 APIs for DWM status.
Once Win32k lockdown is enabled, this API will be unavailable and will need
to be remoted. This new function will be made to work in both parent and
content processes, and therefore all DWM queries must be directed to it.
Also, some minor cleanup because... Why not?
Differential Revision: https://phabricator.services.mozilla.com/D73742
The old code didn't handle content prevent defaulting the input.
The pinch gesture code doesn't seem to fully work properly, it will allow a little pinch zooming before halting it if content is prevent defaulting it. Not sure what is up yet.
Differential Revision: https://phabricator.services.mozilla.com/D73220
We can't just get pinch events, we need to handle both.
This state machine code is basically copied from Chrome's implementation.
Differential Revision: https://phabricator.services.mozilla.com/D71307
