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
We probably need more fixes on top, I see sometimes we get stuck in a
move-to-rect loop (probably because our gtk call doesn't know about the
fractional scale).
But this fixes the sizing and positioning at least.
Differential Revision: https://phabricator.services.mozilla.com/D228602
So the issue here is that my patch made GetTopLevelWidget() return the
top level window across the widget chain, including this one in
particular:
https://searchfox.org/mozilla-central/rev/387f3edbef37d31b2e91fb0812c74b54729e86ff/layout/base/nsDocumentViewer.cpp#2339
We have two AppWindows parented:
* Top level browser -> Alert window.
It seems it's know that cocoa windows that aren't shown yet may have a
HiDPI scale factor different from their actual screen's scale factor:
* https://searchfox.org/mozilla-central/rev/387f3edbef37d31b2e91fb0812c74b54729e86ff/widget/cocoa/nsCocoaWindow.mm#1895-1935
This causes the alert window have a devicePixelRatio of 2 but the top
level have a devicePixelRatio of 1.
Which means that nsDeviceContext thinks we have a DPI of 1, but
AppWindow and co have a DPI of 2, causing this mismatch.
Fix this by making GetTopLevelWidget actually return the nsCocoaWindow
widget for the alert, not the other.
This restores the behavior for cocoa, but changes it for Windows and
Linux (Android can't have nested top level windows, afaict).
Given windows and Linux both had the concept of "top level widget" in a
similar fashion, I think we can try this. I'll add a smaller fix for
uplift purposes.
Differential Revision: https://phabricator.services.mozilla.com/D227875
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
Move mParent to nsIWidget.h along with kids and so on. Instead of
ReparentNativeWidget add a more general DidChangeParent method.
Make mParent weak to prevent cycles. These are broken on Destroy() but
it feels kinda silly, and we were inconsistent before I started this
effort so pretty sure it can be done.
Differential Revision: https://phabricator.services.mozilla.com/D225796
Move mParent to nsIWidget.h along with kids and so on. Instead of
ReparentNativeWidget add a more general DidChangeParent method.
Make mParent weak to prevent cycles. These are broken on Destroy() but
it feels kinda silly, and we were inconsistent before I started this
effort so pretty sure it can be done.
Differential Revision: https://phabricator.services.mozilla.com/D225796
This was implemented in bug 1813554 to allow resizing tiled windows at
the top of the window, but since then KWin has changed behavior and no
longer allows resizing tiled windows, so this is now unnecessary.
Differential Revision: https://phabricator.services.mozilla.com/D226005
This makes us choose the right rounding mode in nsView::CalcWidgetBounds
in order to prevent seams.
Remove composited screen special case which is no longer relevant now
that the X11 shape mask code is gone.
Differential Revision: https://phabricator.services.mozilla.com/D224918
This is all super-hacky (see a lot of the XXXcjones comments).
Simplify it... We never create widgets with a bare native parent but no
nsIWidget parent. Pass nsIWidgets and deal with things correctly.
There were also things that were dealing with stuff that can't happen,
like top level popups, children of PuppetWidgets, or such.
Instead of overriding Create(), let's just teach nsBaseWidget about
non-native (headless/puppet) widgets.
Remove lots of old APIs for the native window stuff that are unused
and/or unimplemented.
Differential Revision: https://phabricator.services.mozilla.com/D224613
Pretty sure that we can't hit that case right now, and try with MOZ_ASSERT
agrees with me at least.
Popups don't get there. For puppet widgets, mParentWidget is provided
explicitly.
This code is all super messy and can be cleaned-up significantly.
See following patch.
Differential Revision: https://phabricator.services.mozilla.com/D224612
A popup attached to a modal parent window doesn't get mouse events
from Gtk as they'are directed to the modal parent. This is usually solved
by pointer grab which that doesn't work on Wayland in our current
setup as it performs show and grab in one step.
We emulate it by setting popup as modal too but then patent
window doesn't get mouse events outside of popup (Bug 1899299).
we need to listen
Surprisingly attaching events handler to mShell fixes it
and we're getting events from both parent and popup windows.
Differential Revision: https://phabricator.services.mozilla.com/D221290
It's only used in non-compositing WMs, to implement popup transparency,
and it's completely untested.
Instead, do not draw shadows and rounded corners on those WMs.
Differential Revision: https://phabricator.services.mozilla.com/D219141
It's only used in non-compositing WMs, to implement popup transparency,
and it's completely untested.
Instead, do not draw shadows and rounded corners on those WMs.
Differential Revision: https://phabricator.services.mozilla.com/D219141
- Move more widget events from mContainer to mShell. We generally want to listen on mShell and use mContainer
for GtkContainer related events only.
- Set correct event masks for mShell/mContainer
Differential Revision: https://phabricator.services.mozilla.com/D216913
