Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
nsContainerFrame.h was only using the enum nsLayoutUtils::IntrinsicISizeType,
which this patch moves to LayoutConstants.h instead.
Depends on D91505
Differential Revision: https://phabricator.services.mozilla.com/D91506
The ability to reverse axes internally was added in bug 983427, but it
turns out not to be used.
test_flex_lines.html needs to be modified because those expected cross
values are written as if the flex lines are physically in top-to-bottom
order (due to we reversed the axes internally).
Now we don't reverse the internal axes, the order of the flex lines
becomes bottom-to-top due to "flex-wrap: wrap-reverse". The crossStart
coordinate begins from the flex container's bottom end edge, and it
increases from bottom to the top to the flex container's top end
edge. (Note the flex container has 42px height.)
Differential Revision: https://phabricator.services.mozilla.com/D75887
This patch basically reverts the functional part of changeset 52bd865d757c.
I'd optimistically hoped we could skip this early-freeze in order to compute &
report a bit more "potential flexing" information via devtools. Bbut it turns
out that breaks assertions & produces bogus information for flex items whose
base size vs. min/max-clamped "hypothetical" sizes are very
different. (Specifically: it produces nonsense for flex items whose base sizes,
if unclamped, would reverse the directionality of flexing.)
Differential Revision: https://phabricator.services.mozilla.com/D9304
--HG--
extra : moz-landing-system : lando
This patch also updates the expectations in the mochitest test_flex_items.html.
Before this commit, the test (incorrectly) expected the mainBaseSize API to
return some items' *final sizes*, because that's what our implementation did
return, up until now. As of this patch, that API will now return the item's
actual flex base size, which means the text expectations need to change.
I'm also adding a new flex item to the test, to exercise a formerly-untested
scenario. And to accommodate this new item, I'm also doubling the width of
the flex container to be sure there's plenty of space.
Differential Revision: https://phabricator.services.mozilla.com/D8476
--HG--
extra : moz-landing-system : lando
Primary changes:
- Rewrap some lines that are too long.
- Adjust some failure-messages with s/has/should have/ etc.
- Replace 'nearlyEqual' function with the standard mochitest
'isfuzzy()' API (which is like 'is()' with an extra epsilon arg)
- Remove dependence on hardcoded element IDs, and simply walk over the
flex container's children in order instead (still noting each child node
and making sure it matches the node in the flex API).
Differential Revision: https://phabricator.services.mozilla.com/D8933
--HG--
extra : moz-landing-system : lando
Primary changes:
- Rewrap some lines that are too long.
- Adjust some failure-messages with s/has/should have/ etc.
- Replace 'nearlyEqual' function with the standard mochitest
'isfuzzy()' API (which is like 'is()' with an extra epsilon arg)
- Remove dependence on hardcoded element IDs, and simply walk over the
flex container's children in order instead (still noting each child node
and making sure it matches the node in the flex API).
Differential Revision: https://phabricator.services.mozilla.com/D8933
--HG--
extra : moz-landing-system : lando
Previously we were just directly converting this nscoord sentinel-value representation (NS_UNCONSTRAINEDSIZE) into CSS pixels and producing a particular bogus number of pixels.
Differential Revision: https://phabricator.services.mozilla.com/D2432
--HG--
extra : moz-landing-system : lando
This patch was autogenerated by my decomponents.py
It covers almost every file with the extension js, jsm, html, py,
xhtml, or xul.
It removes blank lines after removed lines, when the removed lines are
preceded by either blank lines or the start of a new block. The "start
of a new block" is defined fairly hackily: either the line starts with
//, ends with */, ends with {, <