This commit attempts to lower the pain of modifying FrameMetrics.h.
It looks like most includes really only want ViewID or
ScrollableLayerGuid, so this commit factors them out into a separate
header. In the process FrameMetrics::ViewID is changed to
ScrollableLayerGuid::ViewID, which personally seems like a better
place for it now that we have RepaintRequest. Unfortunately that
requires a lot of places to be updated.
After this commit there are still a couple of major places that
FrameMetrics is included.
* nsDisplayList.h
* nsIScrollableFrame.h
* Layers.h
Those are going to be more tricky or impossible to fix so they're
not in this commit.
Differential Revision: https://phabricator.services.mozilla.com/D10722
--HG--
rename : gfx/layers/FrameMetrics.h => gfx/layers/ScrollableLayerGuid.h
rename : gfx/layers/FrameMetrics.h => gfx/layers/ZoomConstraints.h
extra : rebase_source : 29ac79f91460a181bf7437af5c371207e22858e2
extra : source : c2e70e531075493fc6e374dcec862827f0bc6e77
A wrapper for ::GetModuleFileNameW() is needed in multiple places for the
purpose of evaluating and processing untrusted DLLs. This adds the appropriate
wrapper to WinUtils.cpp
Depends on D6240
Differential Revision: https://phabricator.services.mozilla.com/D9163
--HG--
extra : moz-landing-system : lando
Bug 1435827 part 3/9: Add WinUtils::PreparePathForTelemetry;r=aklotz
PreparePathForTelemetry encapsulates our method of removing sensitive
information from file paths for use in telemetry payloads.
SanitizePath() has been essentially renamed to PreparePathForTelemetry()
which is a bit more precise now that it's being used externally.
Untrusted modules evaluation requires a few path transformations to happen at
various places during processing. This is largely because APIs like
GetLongPathNameW can be rather slow, so performance becomes an issue.
That is the justification for breaking out path transformations into separate
wrapper functions and also the need for PathFlags.
Differential Revision: https://phabricator.services.mozilla.com/D6240
--HG--
extra : moz-landing-system : lando
This exposes Gecko networking to GeckoView apps. It includes speculative connections, name resolution, and a Fetch-like HTTP API.
Differential Revision: https://phabricator.services.mozilla.com/D7799
squash to executor
Content process of Android uses sync IPC when initializing LookAndFeel. But
current e10s has LookAndFeel cache for start up of content process.
So we should use it, then remove sync IPC for start up performance
Differential Revision: https://phabricator.services.mozilla.com/D9750
--HG--
extra : moz-landing-system : lando
This combines some of your ideas from D8074, in which I think is quite a big improvement to the overall code.
The code for nsTransferable::GetTransferData, especially nsIFlavorDataProvider is a bit wonky, because I tried to preserve the current behavior.
Differential Revision: https://phabricator.services.mozilla.com/D9599
--HG--
extra : moz-landing-system : lando
This combines some of your ideas from D8074, in which I think is quite a big improvement to the overall code.
The code for nsTransferable::GetTransferData, especially nsIFlavorDataProvider is a bit wonky, because I tried to preserve the current behavior.
Differential Revision: https://phabricator.services.mozilla.com/D9599
--HG--
extra : moz-landing-system : lando
We already have a check for the nvidia vendor id in gfxPlatform.cpp so
we don't need to list all the other vendors explicitly.
Differential Revision: https://phabricator.services.mozilla.com/D9677
--HG--
extra : moz-landing-system : lando
When clicking toast notification window, OnActivate is called. When using
Windows 8, 2nd parameter (IInspectable) might be nullptr.
So when this parameter is nullptr, it should recognize as alertclickcallback
with mClickable=true.
Differential Revision: https://phabricator.services.mozilla.com/D8076
--HG--
extra : moz-landing-system : lando
We've added nsIWidget::GetDesktopToDeviceScaleByScreen which will return scale factor of the newly placed window
according to its position on the display. This change is to move implementation to the nsIWidget derived classes.
We need that for GTK Wayland, because on the Wayland we cannot determine absolute position of the window, we
need to use parent's window scale factor. For other platforms the GetDesktopToDeviceScaleByScreen is implemented
in nsBaseWidget.
Differential Revision: https://phabricator.services.mozilla.com/D7290
--HG--
extra : moz-landing-system : lando
We currently allow the GPU process if we are not hardware accelerated. One of the
reasons we might not use hardware acceleration is because the device vendor is
not in the gfxInfo whitelist. In this case, we should be consistent and still
use the GPU process.
Differential Revision: https://phabricator.services.mozilla.com/D9446
--HG--
extra : moz-landing-system : lando
This also includes implementation of nsNativeThemeCocoa::GetWidgetAutoColor
which should have been done in bug 1464722 actually.
Differential Revision: https://phabricator.services.mozilla.com/D8629
--HG--
extra : moz-landing-system : lando
Running clang-format makes this code at least a bit more pleasant to look at.
Differential Revision: https://phabricator.services.mozilla.com/D8074
--HG--
extra : moz-landing-system : lando
We've added nsIWidget::GetDesktopToDeviceScaleByScreen which will return scale factor of the newly placed window
according to its position on the display. This change is to move implementation to the nsIWidget derived classes.
We need that for GTK Wayland, because on the Wayland we cannot determine absolute position of the window, we
need to use parent's window scale factor. For other platforms the GetDesktopToDeviceScaleByScreen is implemented
in nsBaseWidget.
Differential Revision: https://phabricator.services.mozilla.com/D7290
--HG--
extra : moz-landing-system : lando
