Bug 1278282 removed Gtk2 support, so MOZ_WIDGET_TOOLKIT is always "gtk3"
for Gtk builds, and never "gtk", which makes the current check never
match.
Differential Revision: https://phabricator.services.mozilla.com/D42761
--HG--
extra : moz-landing-system : lando
Until now, `WinUtils::PreparePathForTelemetry` did not whitelist paths
originating from the Windows system directory. This is unfortunate, as those
paths are not going to contain any PII yet may be useful for troubleshooting.
By adding `%SystemRoot%` to the whitelist, such paths will be included after
substituting the real system directory with the name of the environment
variable.
Finally, we need to lazily build the whitelist in a thread-safe manner.
Whitelist construction has been refactored so that the whitelist is a static
local variable that is atomically constructed.
Differential Revision: https://phabricator.services.mozilla.com/D42916
--HG--
extra : moz-landing-system : lando
This also moves the MaybeScheduleUnsuspendAsyncCATransactions() call to the end
of HandleMainThreadCATransaction() so that we can't get re-suspended from within
WillPaintWindow().
Differential Revision: https://phabricator.services.mozilla.com/D42763
--HG--
extra : moz-landing-system : lando
For popup windows with parent we need to get scale factor of the parent
window. Because when the windows are hidden they're not receiving updates
about changing scaling factor. So when moving from normal dpi to
the hidpi monitor the newly opened popup windows will have the same scale
Differential Revision: https://phabricator.services.mozilla.com/D41947
--HG--
extra : moz-landing-system : lando
This can be verified by starting Firefox with the environment variables
CA_LAYER_SURFACE=0 CA_COLOR_OPAQUE=1
Transparent parts of the window will be red, and opaque parts will be green.
With this patch, the main browser window will be opaque except for the vibrant
areas, i.e. the tab bar and any open sidebars, which will be transparent.
Full screen video will be opaque.
Differential Revision: https://phabricator.services.mozilla.com/D40555
--HG--
extra : moz-landing-system : lando
ScreenPixels would be a more appropriate unit. But inside BasicCompositor everything
is in the same coordinate space anyway so we're not getting much benefit from the
units. This patch eliminates a lot of .ToUnknown*() calls.
Differential Revision: https://phabricator.services.mozilla.com/D41680
--HG--
extra : moz-landing-system : lando
On Windows, where the DrawTarget is rewrapped in a Cairo/pixman DrawTarget,
this will now cause Cairo/pixman to be used for the clear.
Differential Revision: https://phabricator.services.mozilla.com/D41673
--HG--
extra : moz-landing-system : lando
This should be equivalent to what we had before but clearer.
Before this patch, we would reallocate the back buffer if
- the back buffer was larger than the client size (meaning the window had shrunk) or
- the invalid region didn't fit in the back buffer.
Whenever the window is resized, we have a frame where the invalid region covers
the entire window, and thus size would be equal clientSize in that frame.
So effectively, the back buffer size was always kept in sync with the client size.
Differential Revision: https://phabricator.services.mozilla.com/D41671
--HG--
extra : moz-landing-system : lando
For launching with an external protocol handler on Windows, we validate a uri
before sending it to `ShellExecute`, by converting a string into `PIDL` using
`SHParseDisplayName` and extract a string back from PIDL using
`IShellFolder::GetDisplayNameOf`. The problem was that if a fragment, a
string following a hash mark (#), is always dropped after this validation.
This is caused by the intended design of Windows.
A proposed fix is to use `CreateUri` for validation, which is used behind
`IShellFolder::GetDisplayNameOf`. However, we also keep `SHParseDisplayName`
because there are cases where `CreateUri` succeeds while `SHParseDisplayName`
fails such as a non-existent `file:` uri and we want to keep the same
validation result for those cases.
Adding `CreateUri` broke MinGW build because of our toolkit issue. We use
dynamic linking for MinGW build in the meantime.
This patch adds a new unittest to make sure the new validation logic
behaves the same as the old one except the fragment issue.
Differential Revision: https://phabricator.services.mozilla.com/D42041
--HG--
extra : moz-landing-system : lando
For launching with an external protocol handler on Windows, we validate a uri
before sending it to `ShellExecute`, by converting a string into `PIDL` using
`SHParseDisplayName` and extract a string back from PIDL using
`IShellFolder::GetDisplayNameOf`. The problem was that if a fragment, a
string following a hash mark (#), is always dropped after this validation.
This is caused by the intended design of Windows.
A proposed fix is to use `CreateUri` for validation, which is used behind
`IShellFolder::GetDisplayNameOf`. However, we also keep `SHParseDisplayName`
because there are cases where `CreateUri` succeeds while `SHParseDisplayName`
fails such as a non-existent `file:` uri and we want to keep the same
validation result for those cases.
This patch adds a new unittest to make sure the new validation logic
behaves the same as the old one except the fragment issue.
Differential Revision: https://phabricator.services.mozilla.com/D42041
--HG--
extra : moz-landing-system : lando
updateLayer expects some objects to be non-null which are only initialized when the pref is set.
But in builds that were compiled with the 10.14 SDK, all NSViews are layer-backed by default, so
wantspdateLayer gets called, and returning YES from that unconditionally will cause updateLayer
to be called.
Differential Revision: https://phabricator.services.mozilla.com/D42333
--HG--
extra : amend_source : a7a1f7ecba9418e3bf5464bca90ba655002bc637
Without this, in windows with title bars, such as the bookmark library window,
the title bar and the content would update at different times.
The title bar paint is done as part of a main thread CoreAnimation transaction.
However, by default, we don't get notified of all main thread CA transactions;
our only notification mechanism is the updateLayer handler on the PixelHostingView,
and that handler is only invoked (the layer is only displayed) if the layer has
been marked as needing display. And by default, window focus changes do not mark
random views' backing layers as needing display. Usually, what this means is that
the window will be painted twice: Once in the main thread transaction, and then
another time on the compositor thread once Gecko has noticed a state change and
triggered its own composite in response. (Often, Gecko's compositor-side paint
will actually happen *before* the main thread paint, because the main thread is
often busy with repainting the system menu bar during window focus changes.)
Such non-atomic window repaints look glitchy.
Calling SuspendAsyncCATransactions will result in a call to updateLayer in the
upcoming CoreAnimation transaction and lets us update the entire window in one
atomic paint, and it will avoid updating the window early if the compositor
thread gets ahead of the main thread.
Differential Revision: https://phabricator.services.mozilla.com/D38759
--HG--
extra : moz-landing-system : lando
Window overlay drawing was added as a workaround for the following:
When our NSOpenGLContext covered the entire window, it would cover the titlebar
contents and hide the window buttons and the title string. It would also not
get anti-aliased rounded corner clipping.
In windows that use CoreAnimation layers for the window frame, this is no longer
a problem, because the CoreAnimation layer tree takes care of these effects:
It applies rounded corner clipping to the window content layers, it puts the
window buttons on top, and it also puts the title string on top if it is shown.
So when we're using CoreAnimation, the existing code needs to be deactivated,
otherwise we'd draw those things twice.
Differential Revision: https://phabricator.services.mozilla.com/D38760
--HG--
extra : moz-landing-system : lando
Now CoreAnimation supports all rendering paths.
The BasicCompositor OMTC path is used when hardware acceleration is disabled,
for example in safe mode or when the user manually disabled it.
Differential Revision: https://phabricator.services.mozilla.com/D38758
--HG--
extra : moz-landing-system : lando
This makes windows that render using CompositorOGL or WebRender show content.
Differential Revision: https://phabricator.services.mozilla.com/D40517
--HG--
extra : moz-landing-system : lando
This makes context menus work. Regular windows are still blank at this point.
This introduces a visual regression on 10.9: context menus and panels now no
longer have a shadow. Only 10.10 and above support shadows on transparent windows
that use CoreAnimation; 10.9 is not able to obtain the shadow shape on those
types of windows.
I think this is an acceptable regression to take. We want to use CoreAnimation
for all window types because it simplifies the code (no need to handle two
paths) and because it avoids expensive mode switches if we realize too late
that a window we just opened is supposed to use CoreAnimation.
Differential Revision: https://phabricator.services.mozilla.com/D40516
--HG--
extra : moz-landing-system : lando
This makes mPixelHostingView layer-backed, and that layer will be empty.
This patch also causes all windows (including context menus, tooltips, arrow
panels etc.) to use CoreAnimation layers for the window frame. This is achieved
by calling setWantsLayer:YES on every window's content view.
After this changeset, all windows will still be empty.
Differential Revision: https://phabricator.services.mozilla.com/D38755
--HG--
extra : moz-landing-system : lando
This patch leaves you with empty windows everywhere. We will build the new
rendering paths from the ground up in the upcoming patches.
Differential Revision: https://phabricator.services.mozilla.com/D38754
--HG--
extra : moz-landing-system : lando
Unlike what the old comment in its drawRect method says, this isn't actually
dependent on the NSFullSizeContentViewWindowMask. Any window that uses
CoreAnimation layers for its window frame will apply these effects automatically.
Differential Revision: https://phabricator.services.mozilla.com/D38753
--HG--
extra : moz-landing-system : lando
We always use OMTC when using OpenGL. We also currently always use OpenGL when using OMTC, but that's about to change.
Differential Revision: https://phabricator.services.mozilla.com/D38752
--HG--
extra : moz-landing-system : lando
BasicLayers is main thread drawing. BasicCompositor is compositor-thread drawing.
Differential Revision: https://phabricator.services.mozilla.com/D38749
--HG--
extra : moz-landing-system : lando
This fixes several tests which snapshot remote windows under Fission. It also
changes some other arbitrary tests that don't use remote windows, which I
changed before I gave up on having an always-async API.
Differential Revision: https://phabricator.services.mozilla.com/D41630
--HG--
extra : rebase_source : 6203b7065f7651e6ed4a2695ff2bd92daec70634
This is needed to let WebRender run on ANGLE/WARP because we end up with
the Microsoft vendor.
Differential Revision: https://phabricator.services.mozilla.com/D41853
--HG--
extra : moz-landing-system : lando
Investigation showed that on this platform the texture unit state becomes
corrupted whenever we set the non-identity swizzling (getting garbage from textureSize()).
Given no easy workaround, we disable swizzling for this GPU family on Mac, for now.
Differential Revision: https://phabricator.services.mozilla.com/D41274
--HG--
extra : moz-landing-system : lando
Under Wayland the GTK does not send the correct window state event change
when the window is iconified. We need to add a workaround for that to avoid
unresponsive UI after restoring the window.
Differential Revision: https://phabricator.services.mozilla.com/D41219
--HG--
extra : moz-landing-system : lando