Remote WebExtension panels can cause us to recreate the widget for a view that
already has a size. In the past, popup widgets were always created with an
initial size of 0x0, so setting the initial size of the ChildView to 0x0
resulted in correct behavior because the window would be resized to the correct
size shortly afterwards, and resize the ChildView along with it via its auto
resizing mask.
When we recreate a widget which already has a known size, setting the initial
size to 0x0 is wrong. We need to set the ChildView's size so that it fills the
contentView of the popup window completely.
MozReview-Commit-ID: 53d3AX3z5h2
--HG--
extra : rebase_source : 7720a6dd12ad7f8efc102cd1430a9e1ed2f5ee0f
This implements the only useful piece of functionality that the
TitlebarAndBackgroundColor class was providing.
MozReview-Commit-ID: FXC6ICgDaoZ
--HG--
extra : rebase_source : fcd5b02ef057199df34459a4361ef7b4184d3a57
We no longer need the ability to specify a background color which gets drawn in
the titlebar. This was the only reason why we were using a textured window.
MozReview-Commit-ID: E8zizuvjjnA
--HG--
extra : rebase_source : ecd4d23e9bb068efbcd192b90e039809bdb451b0
Another patch in this patch series is going to remove our custom window
background color entirely, so we no longer need this override.
MozReview-Commit-ID: 5Hk8jiudzir
--HG--
extra : rebase_source : 24f067726b6c9ce9991dd11df19b726c327eaf05
It looks like the work in bug 1291457 was all that was necessary to get working
window shadows for accelerated popups. It seems that macOS is able to compute
the correct shadow style consistently for whatever is drawn in the
NSOpenGLContext during the first paint of the window (inside the drawRect call
during the orderFront call that opens the window).
We only ran into problems when we animated the contents of the window in a way
that affects the shadow style; we're no longer doing that after bug 1291457.
MozReview-Commit-ID: 62mfWuAsrg2
--HG--
extra : rebase_source : bf8121451474629f0194ccbb422147d5f05ff5b3
extra : source : 57b4a3dff2a5799c5c994a5b577b76c98ebc8226
Looking at the docs for [NSWindow title] I don't think it's supposed to return
nil under any circumstances...
But it does in our automation, for some reason, with the patches for bug 1439875
which make our fullscreen code run a bit earlier.
MozReview-Commit-ID: AX4qzjzsqST
--HG--
extra : rebase_source : a01f2ba6b42b4067e7a4886c4814e85f317a4a6f
The idea is the following:
Behind-window vibrancy is mostly rendered by the window server. For a given
vibrant region of a window, the window server renders a vibrancy "backdrop",
which is a blurred version of everything that's behind that region, modified
with a color tint and blended in some way. Then it puts our actual window
contents on top of that background.
The backdrop's shape is usually a rectangle. If we don't want it to be a
rectangle, we need to tell the window server about the shape that we want it to
be. We can't just "draw" a different shape in our own rendering, because our
own rendering is merely placed on top of the backdrop - but here we want to
modify the shape of the backdrop itself.
NSVisualEffectView lets us set a mask image on the view. If this view is the
content view of a window, then the view will automatically communicate the mask
image to the window server.
Traditionally, our popup windows have had a ChildView as their content view. If
we now want an NSVisualEffectView to be the content view of the window, then we
need to nest the ChildView inside that NSVisualEffectView.
But this NSVisualEffectView is only needed when the window is vibrant and the
vibrancy backdrop needs to have a certain shape. This is the case for our menus
which need to have rounded corners. If the window transitions to being
non-vibrant, or not needing a special shape, then we can go back to the way our
window's NSView hierarchy has worked traditionally. So we need to reparent
NSViews during those transitions.
MozReview-Commit-ID: Bo2VzjhhR0A
--HG--
extra : rebase_source : 9eb463cc68c16c3b9281b57455330969c5e2642c
The idea is the following:
Behind-window vibrancy is mostly rendered by the window server. For a given
vibrant region of a window, the window server renders a vibrancy "backdrop",
which is a blurred version of everything that's behind that region, modified
with a color tint and blended in some way. Then it puts our actual window
contents on top of that background.
The backdrop's shape is usually a rectangle. If we don't want it to be a
rectangle, we need to tell the window server about the shape that we want it to
be. We can't just "draw" a different shape in our own rendering, because our
own rendering is merely placed on top of the backdrop - but here we want to
modify the shape of the backdrop itself.
NSVisualEffectView lets us set a mask image on the view. If this view is the
content view of a window, then the view will automatically communicate the mask
image to the window server.
Traditionally, our popup windows have had a ChildView as their content view. If
we now want an NSVisualEffectView to be the content view of the window, then we
need to nest the ChildView inside that NSVisualEffectView.
But this NSVisualEffectView is only needed when the window is vibrant and the
vibrancy backdrop needs to have a certain shape. This is the case for our menus
which need to have rounded corners. If the window transitions to being
non-vibrant, or not needing a special shape, then we can go back to the way our
window's NSView hierarchy has worked traditionally. So we need to reparent
NSViews during those transitions.
MozReview-Commit-ID: Bo2VzjhhR0A
--HG--
extra : rebase_source : 0434a17e2cddc94715db6a5fd17bc27e2cddd05c
Invalidating a window's shadow is really slow and leads to flickering. Now that
arrow panels don't change their contents during the panel opening animation any
more, their shape stays the same after the first paint, so we don't need the
shadow invalidation functionality for them any more. And as far as I know, we
don't use transparent popups with changing shapes anywhere else.
The system still computes the shadow for the first paint of the window (which
happens during the orderFront call), and it updates the shadow whenever the
window resizes. But not when its size stays the same and only what we draw in
the content is updated.
MozReview-Commit-ID: 138PjbrSFrc
--HG--
extra : rebase_source : fed1c653ca3d88ef8b4e8e55a7d42b29e17a1624
Sebastian Hengst
Tristan Bourvon
Markus Stange
Tooru Fujisawa
Xidorn Quan
Emilio Cobos Álvarez
Stephen A Pohl
Andreea Pavel
Ryan VanderMeulen
Samael Wang
Beekill95
Erica Wright
Edgar Chen
Carsten "Tomcat" Book