This patch adds an upgrader to remove the Gecko Profiler Addon if
it is installed. If the addon was also enabled, it adds the profiler
menu button to the navbar.
Differential Revision: https://phabricator.services.mozilla.com/D67004
--HG--
extra : moz-landing-system : lando
This patch makes it so that the profiler shortcuts work based on the location of
the profiler menu button. It changes it so that if the menu button is in the navbar
or other menus, the shortcuts will work. Otherwise, the shortcuts will be a no-op.
This removes the Tools -> Web Developer - Enable Profiler Menu Button option. By
default on Nightly and Dev Edition the profiler menu button will be available.
On other channels, users must visit profiler.firefox.com.
Differential Revision: https://phabricator.services.mozilla.com/D66785
--HG--
extra : moz-landing-system : lando
data:text/html,<input type=submit> is white-on-white when depressed with
backplating enabled on the GTK light theme, because even though the computed
background-color is white, the actual button background is themed and the color
is not white instead.
This causes problems with the unthemed appearance anyway (<input type=submit
style="-webkit-appearance: none"> and so on), but this is probably worth it
anyway.
Differential Revision: https://phabricator.services.mozilla.com/D68063
--HG--
extra : moz-landing-system : lando
This was an oversight in the HTMLGroupBoxAccessible implementation of NativeName, others trim their whitespaces by default.
Differential Revision: https://phabricator.services.mozilla.com/D68198
--HG--
extra : moz-landing-system : lando
This updates comments to no longer reference the removed CDM 9 interface. Prior
to these changes the comments should have referenced interfaces 9 + 10, but in
some cases the 10 was omitted, so those comments are corrected too.
Depends on D68046
Differential Revision: https://phabricator.services.mozilla.com/D68047
--HG--
extra : moz-landing-system : lando
This patch removes the code that tries to instantiate CDM interface version 9.
This code is no longer needed as Widevine have moved away from this interface.
At the time of writing Chromium have not used this interface for more than a
year, and Mozilla have not shipped CDMs using the interface for at least 6
months.
Differential Revision: https://phabricator.services.mozilla.com/D68046
--HG--
extra : moz-landing-system : lando
`ProcessPoolExecutor` will naturally default to the number of CPUs on
the machine and will also handle edge cases on Windows.
Differential Revision: https://phabricator.services.mozilla.com/D68185
--HG--
extra : moz-landing-system : lando
Because we remove the content blocking allow list permission from the
permission preload list. The permission in the third party window might
not be available when we check it. So, we move to check the allowListed
flag which is passed by the test framework instead of check the
permission.
Depends on D66737
Differential Revision: https://phabricator.services.mozilla.com/D68189
--HG--
extra : moz-landing-system : lando
After we move the IsOnContentBlockingAllowList to the CookieJarSettings.
We suppose to use this in the Document::RequestStorageAccess() since
this would be called in content processes.
Differential Revision: https://phabricator.services.mozilla.com/D66737
--HG--
extra : moz-landing-system : lando
So far, we haven't checked the window's document uri when doing a about
URI check in StorageAccess::InternalStorageAllowedCheck(). This brought
an issue that if the checked page is an about page with the system
principal, for example the 'about:devtools-toolbox' we will miss this
check. Because of the system principal doesn't have a URI. So we need to
check the document URI instead to know if this is a about page.
Differential Revision: https://phabricator.services.mozilla.com/D66481
--HG--
extra : moz-landing-system : lando
We can remove this two permissions from the preload list since we would
only access these two permissions in the parent process. So, it doesn't
need to be sent to content processes anymore.
Differential Revision: https://phabricator.services.mozilla.com/D66215
--HG--
extra : moz-landing-system : lando
We nolonger need to use the ContentBlockingAllowListPrincipal in the
channel because we move to check the IsOnContentBlockingAllowList in the
CookieJarSettings when we do a content blocking allow list check. Also,
we would potentially expose the cross-origin info through the
ContentBlockingAllowListPrincipal in the channel. Hence, we will remove
it from the channel.
Differential Revision: https://phabricator.services.mozilla.com/D66214
--HG--
extra : moz-landing-system : lando
In this patch, we make the UrlClassifierCommon::IsAllowListed() to get
the ContentBlockingAllowListPrincipal from the WindowGlobalParent
instead of from the channel.
Differential Revision: https://phabricator.services.mozilla.com/D66213
--HG--
extra : moz-landing-system : lando
Right now, we have a ContentBlockingAllowListPrincipal in the
WindowGlobalParent. So, the browse element can directly get this
principal from there. And we can stop sending the
ContentBlockingAllowListPrincipal from the content to parent when
OnLocationChange happens.
Differential Revision: https://phabricator.services.mozilla.com/D66212
--HG--
extra : moz-landing-system : lando
Due to the fact that we compute the IsOnContentBlockingAllowList in the
parent process and pass it as a flag to the content processes, we don't
need to do the cache anymore. Because the check would be just to read a
bool from the WindowContext. The cost should be low enough that we don't
need a cache anymore.
Differential Revision: https://phabricator.services.mozilla.com/D66211
--HG--
extra : moz-landing-system : lando
This patch changes two ContentBlockingAllowList::Check() functions,
including the window version and the channel version, to use the
IsOnContentBlockingAllowList boolean in the CookieJarSettings.
Differential Revision: https://phabricator.services.mozilla.com/D66210
--HG--
extra : moz-landing-system : lando
In this patch, we update the IsOnContentBlockingAllowList boolean in the
CookieJarSettings when doing a top-level load. The boolean will be set
in DocumentLoadListener::Open(). And this boolean would be propagated
with the CookieJarSettings. So, we can check this boolean to see if the
top-level site is in the ContentBlockingAllowList.
In addition, we remove setting the ContentBlockingAllowListPrincipal to
the httpBaseChannel in DocumentLoadListener::Open(). Because we can
use the IsOnContentBlockingAllowList directly without the principal.
Differential Revision: https://phabricator.services.mozilla.com/D66209
--HG--
extra : moz-landing-system : lando
In this patch, we add a IsOnContentBlockingAllowList boolean in the
CookieJarSettings. This boolean would be used to indicate whether the
top-level site in in the content blocking allow list.
Differential Revision: https://phabricator.services.mozilla.com/D66208
--HG--
extra : moz-landing-system : lando
After cargo 7caa161, which was included in rust 1.43 nightly 2020-02-23 as part of rust 11530de, if you don't have rustc installed in the normal place (which our CI builders don't) then you need to specify RUSTC explicitly during cargo metadata or else the call will fail. In our build system, the RUSTC wasn't being passed through in RunCbindgen.py.
Differential Revision: https://phabricator.services.mozilla.com/D68086
--HG--
extra : moz-landing-system : lando
During relazification, cleanup any lingering ScriptCounts that the debugger
may have left behind. The debugger/code-coverage do not always clean this up
before releasing their guards against relazification. Previously, a distinct
JSScript instance would eventually have cleaned this up.
Differential Revision: https://phabricator.services.mozilla.com/D68115
--HG--
extra : moz-landing-system : lando
