Depends on D8740.
This changeset replaces calls to ok with 3 arguments to calls with 2 arguments
in situations where the switch does not have a significant impact on the assert.
Differential Revision: https://phabricator.services.mozilla.com/D8741
--HG--
extra : moz-landing-system : lando
Depends on D8739.
This changeset updates calls to ok() that were most likely intended
for is(), but are not working as is.
Differential Revision: https://phabricator.services.mozilla.com/D8740
--HG--
extra : moz-landing-system : lando
This changeset updates all the test that were wrongly using ok() and wanted to
use is() AND for which the assert is still passing without any modification
required.
Differential Revision: https://phabricator.services.mozilla.com/D8739
--HG--
extra : moz-landing-system : lando
Proper native "groupbox" styling depends on the structure of the XBL binding. By restyling the Page Info dialog, the native styling is now unused except for the Print Page Setup dialog on Windows. The native apperance is thus not applied by default anymore, and the "groupbox" element can just be used semantically for accessibility. The Print Page Setup dialog applies the native styling on its own in a way that still works on Windows.
The only other consumers of "groupbox" are the in-content Preferences pages and dialogs. These are updated to use simpler styles that don't depend on the binding structure.
Differential Revision: https://phabricator.services.mozilla.com/D8752
--HG--
extra : rebase_source : af36d911980517f9b53036f4cd4f800c5e20ad22
One important unrelated change this makes is that previously (in my other patches), the only "@" aliases we recognized were the internal "@" aliases in nsSearchService. While I was working on the new test here I realized that engines with user (or test) aliases that start with "@" aren't recognized as having "@" aliases, but why not IMO.
Differential Revision: https://phabricator.services.mozilla.com/D9074
--HG--
extra : moz-landing-system : lando
This bug touches just about every part of the urlbar: UnifiedComplete, the autocomplete binding, the formatter, CSS.
This builds on the patches in bug 1496814 and bug 1496811.
Differential Revision: https://phabricator.services.mozilla.com/D8948
--HG--
extra : moz-landing-system : lando
Support ctrl-n and ctrl-p for navigating down and up (respectively) in the url
bar on macOS. The autocomplete widget will also support the same key bindings.
This functionality matches ctrl-n/ctrl-p behavior on the other major macOS
browsers.
Differential Revision: https://phabricator.services.mozilla.com/D6451
--HG--
extra : moz-landing-system : lando
When defaulting to a null triggering principal, these tests would fail
when loaded remotely. This patch adds explicit system triggering
principal to the loadURI calls.
Differential Revision: https://phabricator.services.mozilla.com/D8461
--HG--
extra : moz-landing-system : lando
* Remove unused xul namespace declaration.
* color and font are inherited, so no need to declare anything.
* Setting -moz-appearance: none on a div element is useless.
Differential Revision: https://phabricator.services.mozilla.com/D8656
--HG--
extra : moz-landing-system : lando
Instead set the cursor from the UA sheet, and allow authors to override it. This
matches what other UAs do.
Differential Revision: https://phabricator.services.mozilla.com/D8640
--HG--
extra : moz-landing-system : lando
This is unrelated to the other changesets in the bug, just a cleanup based on
patterns that have emerged in other attributeChangedCallbacks like in progressmeter
Differential Revision: https://phabricator.services.mozilla.com/D8174
--HG--
extra : moz-landing-system : lando
As outlined by MozXULElement, we:
- delay connectedCallback logic until after parse
- wait for isConnectedAndReady before running attributeChangedCallbacks;r=paolo
Differential Revision: https://phabricator.services.mozilla.com/D8150
--HG--
extra : moz-landing-system : lando
Adding a test to check whether the wakelock state is correct under different situations. However,
the lock state of power manager doesn't equal to the actual platform lock. Now we don't have any
way to detect whether platform lock is set correctly or not, but we can at least make sure the
specific topic's state in power manager is correct.
Differential Revision: https://phabricator.services.mozilla.com/D7355
--HG--
extra : moz-landing-system : lando
There are two reasons for this:
1) It's faster than running the connectedCallback in the middle of document parse, at least for
<radiogroups> in about:preferences
2) It provides a construction sequence more similar to XBL, so the translation from XBL <constructor>
to CE connectedCallback is more likely to be correct. This is because when there is markup like:
<parent-ce><child-ce></child-ce></parent-ce>
the parent-ce node is empty during the first connectedCallback. If we wait for DOMContentLoaded
then the parent-ce has the child-ce node below it.
Differential Revision: https://phabricator.services.mozilla.com/D7944
--HG--
extra : moz-landing-system : lando
The connectedCallback fires after it's already in the DOM, so without this attribute setting [hidden]
will animate it closed.
Differential Revision: https://phabricator.services.mozilla.com/D7930
--HG--
extra : moz-landing-system : lando
For simplicity, we do not support remote-to-non-remote or non-remote-to-remote
nsIWebProgressListener persistence.
Differential Revision: https://phabricator.services.mozilla.com/D7936
--HG--
extra : moz-landing-system : lando
Kearwood "Kip" Gilbert
arthur.iakab
Ciure Andrei
Julian Descottes
Dão Gottwald
Paolo Amadini
Daniel Varga
Drew Willcoxon
Victor Porof
rosston
Alex Gaynor
Jim Chen
Brian Grinstead
Alexander Surkov
Emilio Cobos Álvarez
Mark Striemer
shindli
Noemi Erli
Tiberius Oros
Philipp Hancke
alwu
Qinghao_Jack_Song
Gijs Kruitbosch
Cristina Coroiu
Andreea Pavel
Bryce Van Dyk
Timothy Guan-tin Chien
Mike Conley