This case is expected in the mozlint world (e.g, when running all linters).
This will still print a warning, just a far less scary one and will still
return 0. There is a case to be made that we should silently ignore this as no
other linters print this warning, but it's useful enough to warrant keeping.
Differential Revision: https://phabricator.services.mozilla.com/D37414
--HG--
extra : moz-landing-system : lando
This moves the html plugin enabling from the ./mach command line to the configuration, which means editors can pick this up automatically.
Differential Revision: https://phabricator.services.mozilla.com/D35414
--HG--
extra : moz-landing-system : lando
Since it's not a xul document anymore we can't rely on the xul.js lint preprocessor.
This means we need to remove preprocessor attributes from inline scripts, and tell
lint about the browser window environment.
Differential Revision: https://phabricator.services.mozilla.com/D33207
This is part 1 of the required changes. This just addresses the
storage mechanism and any place that uses experiments in their raw
form. This updates most callers to support studies with multiple
preferences.
We update about-studies to assume only one preference. This seems
counterproductive, but studies with multiple preferences will include
a description field that obviates the need for this.
Differential Revision: https://phabricator.services.mozilla.com/D29293
--HG--
extra : moz-landing-system : lando
[browsertime](https://github.com/sitespeedio/browsertime) is a harness
for running performance tests, similar to Mozilla's Raptor testing
framework. The Performance Team is using it locally with some
success, but we're running a heavily modified toolchain that is
challenging to install. This mach command is intended to be leverage
for getting more folks able to use browsertime easily.
In particular, the version of browsertime that this installs has
nalexander's changes to support testing GeckoView-based vehicles. If
this approach meets with approval, I'll continue to follow-up with
additional configuration and tooling layers to make it even easier to
drive GeckoView-based vehicles.
I elected to piggy-back install on the eslint installation process,
since this is very similar. To that end, I generalized what was there
very slightly. I elected not to try to move the existing code into a
more obvious shared location, although it might be possible, because
it wasn't clear what contexts the existing code would be invoked
from. In particular I wasn't certain the code could rely on a
complete mozbuild checkout.
I did need to ensure the local Node.js binary is early on the PATH;
this was an issue I ran into with my initial Node/Yarn prototyping
many months ago. At heart the issue is that package scripts in the
wild invoke a bare `node` or `npm` command; if there was a culture of
invoking $NODE or $NPM, this wouldn't be necessary. There's no harm
doing it for ESlint, and it will help the next person who wants to
install an NPM package for tooling in this manner.
Differential Revision: https://phabricator.services.mozilla.com/D26820
--HG--
extra : moz-landing-system : lando
[browsertime](https://github.com/sitespeedio/browsertime) is a harness
for running performance tests, similar to Mozilla's Raptor testing
framework. The Performance Team is using it locally with some
success, but we're running a heavily modified toolchain that is
challenging to install. This mach command is intended to be leverage
for getting more folks able to use browsertime easily.
In particular, the version of browsertime that this installs has
nalexander's changes to support testing GeckoView-based vehicles. If
this approach meets with approval, I'll continue to follow-up with
additional configuration and tooling layers to make it even easier to
drive GeckoView-based vehicles.
I elected to piggy-back install on the eslint installation process,
since this is very similar. To that end, I generalized what was there
very slightly. I elected not to try to move the existing code into a
more obvious shared location, although it might be possible, because
it wasn't clear what contexts the existing code would be invoked
from. In particular I wasn't certain the code could rely on a
complete mozbuild checkout.
I did need to ensure the local Node.js binary is early on the PATH;
this was an issue I ran into with my initial Node/Yarn prototyping
many months ago. At heart the issue is that package scripts in the
wild invoke a bare `node` or `npm` command; if there was a culture of
invoking $NODE or $NPM, this wouldn't be necessary. There's no harm
doing it for ESlint, and it will help the next person who wants to
install an NPM package for tooling in this manner.
Differential Revision: https://phabricator.services.mozilla.com/D26820
--HG--
extra : moz-landing-system : lando
***
Bug 1523957 - Part 0: Whitespace changes in tree.js, r=bgrins
***
Bug 1523957 - Part 1.1: Naively convert tree to a custom element, r=bgrins
***
Bug 1523957 - Part 1.2: Properly mixin BaseControl and extend XULTreeElement, r=bgrins
***
Bug 1523957 - Part 1.3: Use Shadow DOM for slotting children, r=bgrins
***
Bug 1523957 - Part 1.4: Properly handle key events in combination with shift modifiers, r=bgrins
***
Bug 1523957 - Part 1.5: Lint for the lint gods in tree.js, r=bgrins, standard8
***
Bug 1523957 - Part 2.1: Naively convert places-tree to a custom element, preserving history, r=bgrins
***
Bug 1523957 - Part 2.2: Lint for the lint gods in places-tree.js, r=bgrins
***
Bug 1523957 - Part 2.3: Fix browser_passwordmgr_editing.js, r=MattN
***
Bug 1523957 - Part 2.4: Fix browser_bookmarksProperties.js, r=bgrins
***
Bug 1523957 - Part 2.5: Make the edit bookmark tree lazily constructed so there aren't any trees left in the browser window markup, r=bgrins
***
Bug 1523957 - Part 2.6: Add eslint globals to places-tree.js, r=bgrins, standard8
--HG--
rename : browser/components/places/content/tree.xml => browser/components/places/content/places-tree.js
