Add prefs for defining expected values in each content blocking category, depend on those prefs to set expectations.
Differential Revision: https://phabricator.services.mozilla.com/D21234
--HG--
extra : moz-landing-system : lando
This adds support for a "post-prompt" that appears dismissed (only the icon showing) when
the browser decides to automatically deny a permission request from a site (either based on
internal heuristics or because the user prefers not to receive permission prompts).
In order to move quickly and not overload the patch I have only implemented the post-prompting
for desktop-notification so far, however, implementing it for other permissions should be
a trivial follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D25415
--HG--
extra : moz-landing-system : lando
This test was not actually testing what it expected, and we need to properly solve that (clearing by hostname across OAs) in bug 1541885.
Differential Revision: https://phabricator.services.mozilla.com/D26249
--HG--
extra : moz-landing-system : lando
This also moves SiteDataTestUtils to have it available in toolkit.
Differential Revision: https://phabricator.services.mozilla.com/D26248
--HG--
rename : browser/base/content/test/sanitize/SiteDataTestUtils.jsm => toolkit/components/cleardata/SiteDataTestUtils.jsm
extra : moz-landing-system : lando
Toolbar buttons are only made focusable when accessed via the keyboard.
As soon as they lose focus, their focusability is removed.
This is done so that clicking them doesn't focus them.
Previously, this meant that if a panel opened, focus couldn't be restored to the button like it should be when the panel was closed, as the button was no longer focusable.
To work around this, use the open="true" attribute set on the button when the panel opens.
If this is detected when the button loses focus, focusability is not removed.
Once focus is restored after the panel closes, things continue as normal.
That is, when the button loses focus for some other reason, its focusability is removed.
Differential Revision: https://phabricator.services.mozilla.com/D26073
--HG--
extra : moz-landing-system : lando
This fixes two bugs. The first is that when the firefox profile migrator doesn't
know which profile to migrate it attempts to fall back to another profile. I
think this was intended to be the default but in bug 1322797 I ended up making
it the current profile, which is the profile we're restoring into now. I think
at this stage the profile directory doesn't even exist so things go wrong.
Changing to use the actual default works but....
When the profile migrator UI doesn't know what profile to migrate from it uses
the default profile. So if the profile you're actually trying to restore is not
the default we'll effectively throw its data into the archive and replace it
with data from the default profile. I'm inclined to say that if the migrator
does not know what profile to migrate from it should error at that point for
safety.
Why would the profile migrator not know what profile to migrate from? Because of
a long-standing text encoding problem. In C++ profile names are encoded in UTF8.
But we try to pass them to JS through an IDL parameter of type ACString. This
does no UTF8 decoding and so JS recieves an incorrect name if the name includes
non-ascii characters and so can't find the profile.
This patch fixes the IDL parameter to AUTF8String which does the decoding
correctly and so JS gets the name correctly.
We should probably think about whether just passing the nsIToolkitProfile object
to the migrator is a better choice here.
Differential Revision: https://phabricator.services.mozilla.com/D26250
--HG--
extra : moz-landing-system : lando
When this handler got changed to an arrow function the reference didn't get
moved onto the scrollbox.
Differential Revision: https://phabricator.services.mozilla.com/D26142
--HG--
extra : moz-landing-system : lando
In the past Screenshots was not permitted to work on addons.mozilla.org, but now with the mozillaAddons permission this restriction has been removed, and so the onboarding exception for addons.mozilla.org no longer needs to exist.
Differential Revision: https://phabricator.services.mozilla.com/D25997
--HG--
extra : moz-landing-system : lando
The Prio pilot project has completed, so we no longer need to add prio-encoded
payloads to the "main" ping.
Differential Revision: https://phabricator.services.mozilla.com/D26004
--HG--
extra : moz-landing-system : lando
Don't use gconf service to get/set default browser as it breaks recent Gnome environment.
Also use XDG_CURRENT_DESKTOP to check actual desktop.
Differential Revision: https://phabricator.services.mozilla.com/D25395
--HG--
extra : moz-landing-system : lando
The `browser_talltabslistener.js` test verifies that (a) certain
`nsIWebProgress` events occur in the correct order and (b) that the events come
from the correct browser. However, the part of the test that listend for
`onStatusChange` messages did not actually confirm that they were triggered or
that the correct number of them were triggered. The ordering of the
`onStatusChange` events with respect to the other `nsIWebProgress` events is
non-deterministic because `onStatusChange` events are filtered through the
`nsBrowserStatusFilter`, which may or may not put them on a delay timer (due to
the message being repeated often).
The presence of this timer makes for a lovely race condition. Now that the
TabChild's onStatusChange event handler is registered earlier (in
`TabChild::Init` instead of the `WebProgressChild.jsm`) we are getting more
`onStatusChange` messages and the race more frequently results in a failing
test. This is due to one of the test cases swapping browsers *but* not
explicitly waiting for all `onStatusChange` events to come in, so the test case
will run with swapped browsers and a `onStatusChange` event from a previous
test case will leak through, causing the test to fail.
The simplest way to fix these tests is to just remove the `onStatusChange`
listeners, since they do not assert whether or not they are received -- the
tests will pass even if no `onStatusChange` events are sent.
Differential Revision: https://phabricator.services.mozilla.com/D25447
--HG--
extra : moz-landing-system : lando
Mike Conley
Dão Gottwald
Ehsan Akhgari
Erica Wright
Gijs Kruitbosch
phoenixabhishek
Johann Hofmann
Bogdan Tara
Nicholas Cowles
James Teh
Dave Townsend
Thomas Wisniewski
Zibi Braniecki
Brian Grinstead
meandave
Ian Bicking
Syeda Asra Arshia Qadri
Cosmin Sabou
Michael Kaply
Ed Lee
Rob Wu
Chris H-C
David Major
ffxbld
Suriyaa Sundararuban
Marco Bonardo
Coroiu Cristina
Martin Stransky
Mark Striemer
Ciure Andrei
Barret Rennie
Andreea Pavel
Luca Greco
Vijay Budhram
Jan-Erik Rediger
Dorel Luca
Hector Zhao