Our version of mozmake in Windows has issues with how it shells out to
commands that contain double-quote characters. For
example:
FOO="bar" $(PYTHON) script.py
behaves differently than:
FOO='bar' $(PYTHON) script.py
With a double-quote anywhere in the command-line, backslashes get
slurped, so Z:\task/foo becomes Z:task/foo, and python fails to open the
file.
The backslash comes from the WORKSPACE variable in Taskcluster, which is
used in many places, so it seems prudent here to simply convert the
backslash to a forward-slash as a workaround for the issue. Another
possible workaround is to change WORKSPACE to use forward-slashes, and
work around any potential issues with that.
Differential Revision: https://phabricator.services.mozilla.com/D34801
--HG--
extra : moz-landing-system : lando
Added a top margin for about:addons inline settings page such that
the paddings would be consistent.
Differential Revision: https://phabricator.services.mozilla.com/D34817
--HG--
extra : moz-landing-system : lando
Tabs use --in-content-box colors as seen in common.css, about:preferences Certificate viewer and about:logins.
Differential Revision: https://phabricator.services.mozilla.com/D35313
--HG--
extra : moz-landing-system : lando
The conditions under which verifymar is built were not aligned with what
kind of setups are actually doing something. For instance
--disable-signmar --enable-verify-mar was building the verifymar library
but not doing anything with it.
OTOH, building with --enable-signmar --disable-verify-mar did build it
but its code was eliminated at link time because it's unused.
Finally, the conditions between modules/libmar/verify/moz.build and
toolkit/mozapps/update/updater/updater-common.build weren't aligned and
broke some non-Linux tier-3 platforms. We remedy the latter by moving
the flags and libraries verifymar needs to verifymar, so that things
that link verifymar inherit them.
And while in the vicinity, replace a use of NSPR_LIBS with the
pseudo-library `nspr` which has the same effect.
Differential Revision: https://phabricator.services.mozilla.com/D34620
--HG--
extra : moz-landing-system : lando
It's unclear to me how this is passing on infra. After bug 1548542, as far as I can tell the only
time this test passes is when it somehow finishes before it does any of the filter testing.
The filter functions as-is (which predates that bug) does not allow these items to be in the
blocklist without something to identify what they're blocking (a guid/name for addons, a
matchXXXXX prop for plugins). Also, we no longer have a separate bucket pref for the extension
blocklist.
Before this patch, when this (rarely) passes for me on the local machine, it does so because
we bail out immediately after the initial run_test, as if the add_task functions have somehow
not registered. I do not understand why this would happen. In any case, after these changes,
we definitely run the rest of the test and it passes for me locally.
Differential Revision: https://phabricator.services.mozilla.com/D35030
--HG--
extra : moz-landing-system : lando
For parity with the XUL about:addons page, this commit adds missing rows
to the details view:
- Bug 1557792 - incognito not_allowed should show "Not Allowed in Private Windows"
- Bug 1551947 - extensions with locked private browsing flag should not
show inputs to control the flag, but "Requires Access to Private Windows"
Differential Revision: https://phabricator.services.mozilla.com/D34936
--HG--
extra : moz-landing-system : lando
For parity with the XUL about:addons page, this commit adds missing rows
to the details view:
- Bug 1557792 - incognito not_allowed should show "Not Allowed in Private Windows"
- Bug 1551947 - extensions with locked private browsing flag should not
show inputs to control the flag, but "Requires Access to Private Windows"
Differential Revision: https://phabricator.services.mozilla.com/D34936
--HG--
extra : moz-landing-system : lando
test_recommendations.js has one test that verifies that an unsigned
add-on is not recommended. In order to load an unsigned add-on, it
needs to disable signing. Signing can however not be disabled when
MOZ_REQUIRE_SIGNING=1. So skip the test if require_signing is set.
Differential Revision: https://phabricator.services.mozilla.com/D34891
--HG--
extra : moz-landing-system : lando
In order for the remote settings blocklist to sync, we need to ensure that
the corresponding remote settings clients are created (see also
https://bugzilla.mozilla.org/show_bug.cgi?id=1557790#c2 ). This is
necessary because the blocklist clients are not in the `main` bucket.
This would otherwise happen as soon as any consumer asked the blocklist
for any block data, but that's not going to happen unless the list of
add-ons or plugins changes. Even if there are no changes to the local
lists of installed things, we do need blocklist updates because
otherwise already-installed items would never get blocked even if/when
they are added to the blocklist.
The client initialization should have no other side effects (in terms of
performance/cost) beyond ensuring they get included in things we ask for
when the update-timer fires.
Differential Revision: https://phabricator.services.mozilla.com/D34550
--HG--
extra : moz-landing-system : lando
Fix browser_webext_incognito.js to work with both XUL and HTML about:addons.
This patch also ensures that (inline) options UI is only shown in HTML
about:addons in private windows if add-ons are allowed access to it.
browser_webext_incognito.js serves as a unit test for this.
Differential Revision: https://phabricator.services.mozilla.com/D34277
--HG--
extra : moz-landing-system : lando
