This is the only <radiogroup> and <radio> consumer in browser.xul.
By making the DOM get constructed on demand, we can avoid connecting
radios at startup, and it also gives us a chance to migrate the
strings to Fluent.
Differential Revision: https://phabricator.services.mozilla.com/D24914
--HG--
extra : moz-landing-system : lando
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
`nsChildView::GetEditorView()` is called by `TextInputHandlerBase::GetWindowLevel()`
which is called when Cocoa requests window level of focused widget.
It currently gets widget including focused element (e.g., it may be in a XUL
`<panel>`) with `eQueryTextContent` event. However, it requires only the widget
(i.e., when a XUL `<panel>` has focused element, the widget for the panel).
Therefore, it does not require to flush the layout.
However, on macOS, `ContentEventHandler` always flushes layout even with
`eQueryContentState` which does not require any layout information. Whether
it requires flushing layout or not is considered with
`WidgetQueryContentEvent::mNeedsToFlushLayout` but this is set to false only
when `IMEContentObserver` notifies widget (and IME) of focus set. At this
time, only on macOS, IME caches the layout information, for example, the
character coordinates, but we don't have a way to update it. This is the reason
why we always flush layout on macOS.
Unfortunately, when a menu popup frame is created, widget for the popup is
created synchronously. Then, Cocoa retrieves window level of the widget including
focused element. But this is unsafe to flush the layout. So, we need to stop
flushing layout in this case.
Therefore, this patch moves the `#ifdef` from `TextEvents.h` to
`IMEContentObserver.cpp`, then, makes `nsChildView::GetEditorView()` use
`eQueryContentState` which is the simplest query content event, and finally,
sets `mNeedsToFlushLayout` to `false`.
Differential Revision: https://phabricator.services.mozilla.com/D25912
--HG--
extra : moz-landing-system : lando
Disable early sandbox init for the RDD Mac process until the 10.11 crash is resolved.
Differential Revision: https://phabricator.services.mozilla.com/D25690
--HG--
extra : moz-landing-system : lando
I also updated the logic to properly cycle through the visible search engines list
and added a unit test that was missing, somehow.
Differential Revision: https://phabricator.services.mozilla.com/D25368
--HG--
extra : moz-landing-system : lando
Stop using --panel-disabled-color for subviewbutton shortcuts (where the subviewbutton is also a menuitem)
Differential Revision: https://phabricator.services.mozilla.com/D25521
--HG--
extra : moz-landing-system : lando
As discussed on IRC, fixed is only used for prefs right now, and:
* We already copy the fixed size to the monospace font.
* We already serialize the fixed family as "monospace" in the style system.
So it already works somewhat inconsistently. Making it an alias makes it
work consistently.
Differential Revision: https://phabricator.services.mozilla.com/D24288
--HG--
extra : moz-landing-system : lando
The problem was that it only apply changes when the user clicks on save button, so, some times there is a permission that has to be added but is also in the permissions to delete, so, the solution is just delete all the permissions it has to delete first and then add the permissions that has to be added. r=johannh
Differential Revision: https://phabricator.services.mozilla.com/D23952
--HG--
extra : moz-landing-system : lando
Disabled plugin related tests.
Added `crashreporter` dependency for browser_restore_isAppTab.js.
Differential Revision: https://phabricator.services.mozilla.com/D25504
--HG--
extra : moz-landing-system : lando
As discussed on IRC, fixed is only used for prefs right now, and:
* We already copy the fixed size to the monospace font.
* We already serialize the fixed family as "monospace" in the style system.
So it already works somewhat inconsistently. Making it an alias makes it
work consistently.
Differential Revision: https://phabricator.services.mozilla.com/D24288
--HG--
extra : moz-landing-system : lando
- `onProgressiveData` callback is never set, so everything that is
conditional on it can be removed.
- `loadedRequests` has never been used, it can be removed.
- Several other methods are unused and not part of any interface;
These can also be removed.
Differential Revision: https://phabricator.services.mozilla.com/D24745
--HG--
extra : moz-landing-system : lando
Daniel Varga
Ryan VanderMeulen
ffxbld
Ricky Rosario
Andrea Marchesini
danielleleb
Brian Grinstead
Dão Gottwald
Matt Howell
Mike Conley
Ehsan Akhgari
Erica Wright
Gijs Kruitbosch
phoenixabhishek
Johann Hofmann
Bogdan Tara
Nicholas Cowles
James Teh
Dave Townsend
Thomas Wisniewski
Zibi Braniecki
meandave
Ian Bicking
Syeda Asra Arshia Qadri
Cosmin Sabou
Michael Kaply
Ed Lee
Rob Wu
Chris H-C
David Major
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
Masayuki Nakano
Sebastian Streich
Haik Aftandilian
Mike de Boer
Mark Banner
Khyati Agarwal
Jonas Allmann
Thomas Nguyen
Mike Hommey
Noemi Erli
Sam Foster
Emilio Cobos Álvarez
Carolina Jimenez Gomez
Edwin Gao
arthur.iakab
Paul Zuehlcke
Marco Castelluccio
Tom Schuster
Henri Sivonen
Sylvestre Ledru