This event is used for shield-study which has finished, so we could remove it.
Differential Revision: https://phabricator.services.mozilla.com/D14810
--HG--
extra : moz-landing-system : lando
We've handle showing the blocking icon in patch2, so we don't need to set block permission in PermissionUI.
Differential Revision: https://phabricator.services.mozilla.com/D14797
--HG--
extra : moz-landing-system : lando
The only uses of "listheader" are part of in-content preferences, and they are updated to use adjacent elements. This is in preparation for the removal of the inner scrollbox in the "richlistbox" binding.
Differential Revision: https://phabricator.services.mozilla.com/D15387
--HG--
extra : rebase_source : 0def7dd7417d65449c7d4f8f35bb7361e243783e
In addition to the visual improvement, these icons help the responsive design of the page, because if it becomes too narrow the sidebar labels will disappear and only the icons will be displayed
Instead of opening the pop-up permissions dialog with the origin already populated, this command now highlights the pop-up permission row in the preferences. This doesn't remove any functionality because the only action that would be available for the origin in the permissions dialog is "Allow", which is equivalent to the "Allow pop-ups for" command in the notification bar menu.
Differential Revision: https://phabricator.services.mozilla.com/D15066
--HG--
extra : rebase_source : 064b3d39dc2a8c4d6a3c0949a51ab361ed6e71dd
If we QI nsIPropertyBag on an XPCWrappedNative wrapping an XPCWrappedJS, calling
the getProperty method might incorrectly end up calling .getProperty on the
XPCWrappedJS itself, because it also implements nsIPropertyBag.
This became a problem with same-compartment chrome globals because if we no longer
cross a compartment boundary, we don't create a new WrappedNative and can now end up
seeing the nsIPropertyBag if it got queried before nsIWritablePropertyBag.
Depends on D15076
Differential Revision: https://phabricator.services.mozilla.com/D15077
--HG--
extra : moz-landing-system : lando
It was added in case there were CDN issues with downloading unthrottled and
since there haven't been any issues it is no longer needed.
This was suggested by rstrong and simplifies the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D15076
--HG--
extra : moz-landing-system : lando
When focused, the Back and Forward buttons previously couldn't be activated by pressing space or enter.
Although they do have a command event handler, they have type="menu", which means the command event is not fired for key presses by default.
Since these buttons are special (in that they have type="menu" and a command event), this change implements specific keyboard behavior for these buttons.
Differential Revision: https://phabricator.services.mozilla.com/D12868
--HG--
extra : moz-landing-system : lando
1. Fix the Firefox menu button so that it only handles space and enter, rather than incorrectly activating for *all* key presses.
2. Add keyboard support (space and enter) for the Library and page Actions buttons.
3. Add keyboard support (space and enter) for customizable widgets of type "view"; e.g. the Developer button.
4. Add keyboard support (space and enter) for page action buttons pinned to the URL bar; e.g. the Send Tab to Device button.
Differential Revision: https://phabricator.services.mozilla.com/D11608
--HG--
extra : moz-landing-system : lando
Ryan VanderMeulen
Paolo Amadini
Michael Kaply
Ciure Andrei
Bogdan Tara
alwu
Vedant Nevetia
Jan-Ivar Bruaroey
Gijs Kruitbosch
arthur.iakab
Dão Gottwald
Cosmin Sabou
Margareta Eliza Balazs
Razvan Maries
Adnan Bhuiyan
Ehsan Akhgari
Jared Wein
Andreea Pavel
Raul Gurzau
Jan de Mooij
James Teh