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
Extracts out the creation of an NSEvent from a WidgetKeyEvent in
TextInputHandler.mm into generic helper method. The helper is used by headless
to create a fake NSEvent to then build edit commands from key events.
Fixes:
- test_selectevents.html
- test_bug756984.html
- test_movement_by_characters.html
- test_movement_by_words.html
- test_backspace_vs.html
- test_bug1094000.html
- ... many key event tests
MozReview-Commit-ID: 1Jur5MHOrkp
--HG--
extra : rebase_source : fbe320aff8fd2e1b36f3b46e02336e9fc89c48d0
We can use kPMDataFormatXMLCompressed parameter when storing the page format
data. As result, this preference data will be 20 times smaller.
MozReview-Commit-ID: HMQzhodQyA
--HG--
extra : rebase_source : 941a30cb346b6c15f5a02f527063a437ae0c6121
As per the TODO, a size change on an image is supported now, so there should be
no need to delete and re-create the image key when the window overlay image
changes size. And since the cleanup function is not invoked from anywhere else
it can also be removed.
MozReview-Commit-ID: JSmK5YmXjlX
--HG--
extra : rebase_source : 0078ccfed9a381c82bcb906a87bdf58d8e9c78e1
The window buttons are drawn as part of the AddWindowOverlayWebRenderCommands
function which is invoked in the full-transaction codepath. It should be possible
to have the empty transaction codepath simply update the image (without building
a full WR display list) and do a recomposite. That would be more performant but
it requires some plumbing to build and ship across a IpcResourceUpdateQueue on
empty transactions.
MozReview-Commit-ID: 2Mrb0wELD6E
--HG--
extra : rebase_source : 9a94c32f94403050835bf3445176f4fe2c1579fa
We queried 'loadingprincipal' attribute on the common call path, however
this should be queried if it's loaded by System Principal.
Also rename loadingprincipal to triggeringprincipal
Gecko set job using by PMPrintSettingsSetJobName regardless of job name length.
But IPP allow job-name length up to 255 bytes. (RFC 2911, Section 4.3.1)
This patch will shorten print job name. It is workaround until fixed the
Core Printing[1].
[1] https://openradar.appspot.com/34428043
MozReview-Commit-ID: 6nCwZuD43O9
--HG--
extra : rebase_source : c9c3830890f1f4d84e148fbe281589c23e7803d2
