We no longer have the parent/child window set-up for popups, so we can
just use mWnd.
Remove the HideWindowChrome() stuff. That landed once already in [1],
but was backed out along with other stuff, due to it causing buttons to
show up on non-native notifications (which is the only top level that
hits this code-path).
Eventually, I want to handle this more like other platforms (via D209502
and D207303) but until those land, just explicitly set hidechrome="true"
on that window in order to be able to land this simplification
separately.
Bug 1454589 doesn't happen with this change, and there's no reason to
apply size mode in SetWindowTranslucencyInner, so remove that chunk of
code too.
[1]: https://hg.mozilla.org/mozilla-central/rev/24dc60b32e21
Differential Revision: https://phabricator.services.mozilla.com/D218635
The previous patchset failed to properly convert the RECT to be cleared
from screen- to window-coordinates. (This wasn't noticed because the two
only differ when nontrivial chrome such as the titlebar is present,
which by default it's not.)
Differential Revision: https://phabricator.services.mozilla.com/D214334
This comes back to bug 42557 and co. It only does something
half-reasonable on Windows (on macOS we just lie and make z-order
tracking be latest-active tracking), and given we don't use the special
zorder flags elsewhere I'm pretty sure we should be able to just rip
this off... On some DEs like Wayland we can't re-stack toplevel windows.
Differential Revision: https://phabricator.services.mozilla.com/D213602
DWM will draw our window's surface before we get a chance to clear it:
specifically it will draw the window immediately upon ::ShowWindow(),
and we cannot draw to the window surface before that.
We can, however, _cloak_ the window before showing it; this causes DWM
not to composite it until it's uncloaked. A cloaked window still has a
drawable surface, though, so we just manually clear the window with an
appropriate color before its uncloaking.
Differential Revision: https://phabricator.services.mozilla.com/D212762
This never worked according to its description: it merely set the
_window-class_ background-color. We neither have nor need any mechanism
to give individual windows their own per-widget background color under
Win32.
Instead, we just set the background color to be dark grey, which is
probably good enough for the few purposes for which the background brush
is actually used. (Alas, this does not _quite_ include the initial white
flash.)
The comment in this bug about this being important for Windows dates
from bug 574638, and is no longer relevant -- at least, not in the
particular way it used to be.
Differential Revision: https://phabricator.services.mozilla.com/D212761
`eContextMenu` event may be fired from `widget`. Therefore, different from
`ePointerClick` and `ePointerAuxClick`, they may cross the process boundary,
may be handled by APZ and may be dispatched into the DOM after a delay.
Therefore, this patch is complicated than the previous patch. This adds
* New IPC message handlers for sending/receiving a `WidgetPointerEvent`
* New `DelayedPointerEvent` class and templated `MouseInput::ToWidgetEvent`
* `PresShell::EventHandler` handles `eContextMenu` as same as `WidgetMouseEvent`
Differential Revision: https://phabricator.services.mozilla.com/D213003
See comment in the bug.
This was needed for bogus mouse drivers back in the XP/Vista era.
However Win10/11 sends wheel messages to the window under the cursor
instead of focused window, so these kinds of issues shouldn't arise
there. Try to remove this legacy hack.
Differential Revision: https://phabricator.services.mozilla.com/D210302
This prevents dialog windows created with no borders etc from ending up
with a border anyways, for example, which is relevant for things like
the non-native notifications.
Before this patch, for the non-native notifications case, this was
papered due to the fact window transparency implied HideWindowChrome(),
which unset these bits anyways. But that was pretty
action-at-a-distance...
Differential Revision: https://phabricator.services.mozilla.com/D209502
This is completely obsolete according to MSDN, and it's better
not having to think about it. Doesn't seem needed for regular
dialogs.
Differential Revision: https://phabricator.services.mozilla.com/D209501
Otherwise we start painting the window too early, which after
bug 1891063 causes the non-client area to be filled, but we don't paint
anything on top.
Differential Revision: https://phabricator.services.mozilla.com/D208898
This makes sure that the transparent area is cleared properly.
We move the clear to a point where Gecko has already informed us of
the opaque region for simplicity.
Differential Revision: https://phabricator.services.mozilla.com/D207302
Again, dead code for now because the windows are always opaque,
but will be useful later on since this allows restricting the
region that needs to have transparency.
Differential Revision: https://phabricator.services.mozilla.com/D207301
All the comments on this function are for platforms we don't support.
Right now we don't have any of these top-level transparent windows, but
we want to use DWM and Webrender for these just like for regular windows.
Differential Revision: https://phabricator.services.mozilla.com/D207299
This was needed to get the right border status to paint (bug 586228).
That was a long time ago and nowadays all our windows don't have the
thick themed borders that we used to have.
There are two exceptions here where we draw OS-provided borders on Win
10+:
* High Contrast Mode.
* Accent color settings on windows to show the accent color on window
borders and titlebar.
Both of them look good from here (though I only tested win 11).
Differential Revision: https://phabricator.services.mozilla.com/D207327
All the comments on this function are for platforms we don't support.
Right now we don't have any of these top-level transparent windows, but
we want to use DWM and Webrender for these just like for regular windows.
Depends on D207298
Differential Revision: https://phabricator.services.mozilla.com/D207299
Right now, we don't use top level transparent windows (they're
completely unused).
This removes some code that causes trouble when reintroducing them.
Depends on D207297
Differential Revision: https://phabricator.services.mozilla.com/D207298
No behavior change intended. I plan to use this to hide the titlebar
buttons when drawing to the titlebar (we currently draw on top of them).
But seems worth factoring out regardless.
Differential Revision: https://phabricator.services.mozilla.com/D207297
When stripping and restoring window chrome, don't modify or retain any
style-flags other than window-chrome flags.
This also lets us remove, without further consideration, a tiny bit of
thirteen-year-old special-case logic (dating back to bug 629860) which
tried to fix up the then-improperly-cached `WS_VISIBLE` flag.
Differential Revision: https://phabricator.services.mozilla.com/D206081
I did consider the pref in my patches in bug 1886371.
nsWindow does a QI to IRawElementProviderSimple, which will deliberately fail if the UIA pref is disabled.
Unfortunately, i neglected to realise that it's already too late by that stage because we've already called nsWindow::GetAccessible, which instantiates the a11y engine.
Now, we check the UIA pref before we call GetAccessible.
Differential Revision: https://phabricator.services.mozilla.com/D205559
1. Respond to WM_GETOBJECT with our IRawElementProviderSimple implementation for the root Accessible of the HWND.
2. Don't allow QueryInterface to UIA interfaces if the UIA pref is disabled. This stops WM_GETOBJECT from returning our UIA implementation in this case.
3. Specify the appropriate provider options.
Differential Revision: https://phabricator.services.mozilla.com/D205179
I think we should start off with this. Other platforms can implement
this too, but exposing this to content seems like quite the rabbit hole.
Differential Revision: https://phabricator.services.mozilla.com/D203405
I think we should start off with this. Other platforms can implement
this too, but exposing this to content seems like quite the rabbit hole.
Differential Revision: https://phabricator.services.mozilla.com/D203405
Firefox never uses this. TB could use the same approach Firefox uses,
but for now on macOS the sheets become regular modal dialogs, which is
the same as on Windows and Linux.
See bug 1755330 and bug 1737489 for more context.
Differential Revision: https://phabricator.services.mozilla.com/D204209
We disable the root window when a picker opens.
When the picker closes, our window will get focus, but it will still be disabled.
This confuses the focus system.
Therefore, we ignore this focus and explicitly notify the focus system once we re-enable the window.
Since Windows picker dialogs have regressed accessibility several times now, I also added a Windows accessibility test.
Differential Revision: https://phabricator.services.mozilla.com/D203717
These two features are totally unused and poorly supported.
Both were added in bug 552982, and Wayland doesn't support (nor have a
way of supporting) any of them.
Differential Revision: https://phabricator.services.mozilla.com/D204222
This might be useful for apps to find out the maximize button position
without having to enable UIAutomation. Though it seems Windows doesn't
use this, at least.
Co-authored-by: James Teh <[email protected]>
Differential Revision: https://phabricator.services.mozilla.com/D203422
Makoto Kato