This patch moves NowIncludingSuspendMs() and NowExcludingSuspendMs() into
dedicated files (Now.h and Now.cpp) to improve discoverability and reusability.
Differential Revision: https://phabricator.services.mozilla.com/D243624
This patch adds a helper class for using DbgHelp in StackWalk.cpp. It
also ensures that we use a unique identifier as a HANDLE for DbgHelp
APIs, instead of GetCurrentProcess() which can be used by other code
running within our process.
Differential Revision: https://phabricator.services.mozilla.com/D229134
Unhide our buttons instead, which fixes the caption button sizes when
Mica is enabled.
Crucially (and this is what I had failed to do in my original attempts),
we need to keep WS_MAXIMIZEBOX for Snap Layouts and Aero snap to keep
working. WS_MINIMIZEBOX doesn't hurt either.
This is a bit scary, because we're in undocumented territory, but afaict
(looking with winspy), MS Edge does the same for its custom titlebar, so
I think this is probably safe. It's early in the cycle anyways...
Make the pre-xul skeleton UI flags more consistent while at it.
WS_OVERLAPPED is zero, and WS_SIZEBOX is the same as WS_THICKFRAME (so
there's no change other than removing WS_SYSMENU), but that way it
matches nsWindow::WindowStyle more directly.
In order to not fully lose the system menu functionality, reuse the
functionality we already have to show it on fullscreen windows (which
already lack these styles). Note that this also fixes a bug on which, if
you have a fullscreen window in a non-primary monitor, the system menu
shows up in the primary monitor instead of in your window.
Differential Revision: https://phabricator.services.mozilla.com/D230722
This is probably also a better reflection of reality now that we can
have vertical tabs which would by definition not be in the titlebar.
Differential Revision: https://phabricator.services.mozilla.com/D229767
There are probably other simplifications that can be done after this on the
windows side of things, but I tried to keep this minimal.
Differential Revision: https://phabricator.services.mozilla.com/D229765
Windows 10 and 11 don't have fat windows, so this is unnecessary and
breaks other effects like the accent-color border (if you have "Show
accent color on titlebar and window borders" enabled).
We need to make the custom resize margin thing we have for PiP not mess
with our non-client area, but that is trivial.
Differential Revision: https://phabricator.services.mozilla.com/D229270
These only do something on Windows, and after windows 7 they are not
useful at all.
If this has no fallout I plan to simplify the code further in a
follow-up (we can basically make this a boolean attribute again or so).
Differential Revision: https://phabricator.services.mozilla.com/D228528
This is probably also a better reflection of reality now that we can
have vertical tabs which would by definition not be in the titlebar.
Differential Revision: https://phabricator.services.mozilla.com/D229767
There are probably other simplifications that can be done after this on the
windows side of things, but I tried to keep this minimal.
Differential Revision: https://phabricator.services.mozilla.com/D229765
Windows 10 and 11 don't have fat windows, so this is unnecessary and
breaks other effects like the accent-color border (if you have "Show
accent color on titlebar and window borders" enabled).
We need to make the custom resize margin thing we have for PiP not mess
with our non-client area, but that is trivial.
Differential Revision: https://phabricator.services.mozilla.com/D229270
These only do something on Windows, and after windows 7 they are not
useful at all.
If this has no fallout I plan to simplify the code further in a
follow-up (we can basically make this a boolean attribute again or so).
Differential Revision: https://phabricator.services.mozilla.com/D228528
We always have Dwm{Get,Set}WindowAttribute because we fail if we can't
load them.
This in practice means that we release the DC and uncloak the window a
bit later (due to the MakeScopeExits), but I think that's fine.
Differential Revision: https://phabricator.services.mozilla.com/D229267
These only do something on Windows, and after windows 7 they are not
useful at all.
If this has no fallout I plan to simplify the code further in a
follow-up (we can basically make this a boolean attribute again or so).
Differential Revision: https://phabricator.services.mozilla.com/D228528
These only do something on Windows, and after windows 7 they are not
useful at all.
If this has no fallout I plan to simplify the code further in a
follow-up (we can basically make this a boolean attribute again or so).
Differential Revision: https://phabricator.services.mozilla.com/D228528
Unlike the previous patch this does change behavior, but I think it's
fine.
The reason we used the non-lwt toolbar colors for customize mode is to
guarantee full opacity, see bug 1762379 and bug 1765685.
However, we need to do the same on the sidebar, and there we chose a
more theme-friendly way of doing that, which allows this simplification.
So do that instead.
Differential Revision: https://phabricator.services.mozilla.com/D228523
MOZ_RUNINIT => initialized at runtime
MOZ_CONSTINIT => initialized at compile time
MOZ_GLOBINIT => initialized either at runtime or compile time, depending on template parameter, macro parameter etc
This annotation is only understood by our clang-tidy plugin. It has no
effect on regular compilation.
Differential Revision: https://phabricator.services.mozilla.com/D223341
This doesn't take on the task of also drawing the sidebar, as gathering state for that
is a little more complex to do. Purely removing the flicker from the top of the window
(and potential user confusion about why there is a horizontal tab there) seems a
worthwhile improvement.
Differential Revision: https://phabricator.services.mozilla.com/D226822
On 64-bit Windows (x86_64, aarch64), stack walking relies on
RtlLookupFunctionEntry to navigate from one frame to the next. This
function acquires up to two ntdll internal locks when it is called.
The profiler and the background hang monitor both need to walk the
stacks of suspended threads. This can lead to deadlock situations,
which so far we have avoided with stack walk suppressions. We guard some
critical paths to mark them as suppressing stack walk, and we forbid
stack walking when any thread is currently on such path.
While stack walk suppression has helped remove most deadlock situations,
some can remain because it is hard to detect and manually annotate all
the paths that could lead to a deadlock situation. Another drawback is
that stack walk suppression disables stack walking for much larger
portions of code than required. For example, we disable stack walking
for LdrLoadDll, so we cannot collect stacks while we are loading a DLL.
Yet, the lock that could lead to a deadlock situation is only held
during a very small portion of the whole time spent in LdrLoadDll.
This patch addresses these two issues by implementing a finer-grained
strategy to avoid deadlock situations. We acquire the pointers to the
internel ntdll locks through a single-stepped execution of
RtlLookupFunctionEntry. This allows us to try to acquire the locks
non-blockingly so that we can guarantee safe stack walking with no
deadlock.
If we fail to collect pointers to the locks, we fall back to using stack
walk suppressions like before. This way we get the best of both worlds:
if we are confident that the situation is under control, we will use the
new strategy and get better profiler accuracy and no deadlock; in case
of doubt, we can still use the profiler thanks to stack walk
suppressions.
Differential Revision: https://phabricator.services.mozilla.com/D223498
On 64-bit Windows (x86_64, aarch64), stack walking relies on
RtlLookupFunctionEntry to navigate from one frame to the next. This
function acquires up to two ntdll internal locks when it is called.
The profiler and the background hang monitor both need to walk the
stacks of suspended threads. This can lead to deadlock situations,
which so far we have avoided with stack walk suppressions. We guard some
critical paths to mark them as suppressing stack walk, and we forbid
stack walking when any thread is currently on such path.
While stack walk suppression has helped remove most deadlock situations,
some can remain because it is hard to detect and manually annotate all
the paths that could lead to a deadlock situation. Another drawback is
that stack walk suppression disables stack walking for much larger
portions of code than required. For example, we disable stack walking
for LdrLoadDll, so we cannot collect stacks while we are loading a DLL.
Yet, the lock that could lead to a deadlock situation is only held
during a very small portion of the whole time spent in LdrLoadDll.
This patch addresses these two issues by implementing a finer-grained
strategy to avoid deadlock situations. We acquire the pointers to the
internel ntdll locks through a single-stepped execution of
RtlLookupFunctionEntry. This allows us to try to acquire the locks
non-blockingly so that we can guarantee safe stack walking with no
deadlock.
If we fail to collect pointers to the locks, we fall back to using stack
walk suppressions like before. This way we get the best of both worlds:
if we are confident that the situation is under control, we will use the
new strategy and get better profiler accuracy and no deadlock; in case
of doubt, we can still use the profiler thanks to stack walk
suppressions.
Differential Revision: https://phabricator.services.mozilla.com/D223498
This maps better to the code we have in nsWindow, and fixes a couple
bugs which caused maximized skeleton UI-consuming windows to be
mispositioned with the following patches.
Differential Revision: https://phabricator.services.mozilla.com/D225100
This maps better to the code we have in nsWindow, and fixes a couple
bugs which caused maximized skeleton UI-consuming windows to be
mispositioned with the following patches.
Differential Revision: https://phabricator.services.mozilla.com/D225100
