This should make us agree with other browsers re the serialization of
`"vert" 0`, and with servo after https://github.com/servo/servo/pull/19918
Left try running, may need some test adjustments that I'll send for review if
they're non-trivial.
Differential Revision: https://phabricator.services.mozilla.com/D539
MozReview-Commit-ID: LgIPfn4lfrF
This change is in response to this CSSWG resolution:
"RESOLVED: compute min-width/min-height: auto to auto"
https://github.com/w3c/csswg-drafts/issues/2230#issuecomment-362009042
...which was later clarified as only being applicable to grid/flex items (in
both axes). Other layout modes may get further min-width/min-height
clarification, but for now we'll leave that behavior the same (returning 0 from
getComputedStyle).
MozReview-Commit-ID: 2wLYDAOj9I6
--HG--
extra : rebase_source : c5f384ef5ae906e20a6e10da20c39b0a5eb226eb
We'd like to install the NDK through the Android SDK manager. But we
can't pin versions of the NDK with the SDK manager, and so Google
can silently upgrade the NDK on us. Since that is undesirable, this is
the next best thing.
With the toolchain task in hand, we can make all the relevant tasks
depend on the toolchain task and remove the download of the NDK from
tooltool as well.
style: Cleanup and remove unused / dubious Length stuff.
On top of #19918, turns out that the parse_numbers_are_pixels stuff is unused.
Source-Repo: https://github.com/servo/servo
Source-Revision: a07002a0f0547c1da9043d9e02a308edb0d54232
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : bb3befc36837c7f57dd3ed97fe43305147e8b649
This patch enables generating a JSON file that mirrors the scalar definitions
in Scalars.yaml. On local developer builds, this file is loaded when Firefox
starts to register all the scalars. If some change was introduced in the
definition files, the new scalar will be dynamically added.
The JSON definition file will be regenerated every time an artifact build
is performed or the build faster command is invoked.
MozReview-Commit-ID: Do3WjE38aIK
--HG--
extra : rebase_source : 2d9701d77abeb6ce8de096674349b6d071c4b102
<!-- Please describe your changes on the following line: -->
This is a sub-PR of #19015
Code does not yet compile with `build-geckolib`.
r? emilio
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes fix#19387
<!-- Either: -->
- [x] These changes do not require tests
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
Source-Repo: https://github.com/servo/servo
Source-Revision: 38ef515463338d1c562381fd650b80272f552dfb
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 544c775ece36dbd68987a435e2df56c462cd64dc
style: Move border-image-repeat outside of mako.
This is a rebased / nitpick-addressed / bug-fixed version of #19021, and with a commit from #19668 renaming the two `RepeatKeyword`s to different names.
Source-Repo: https://github.com/servo/servo
Source-Revision: d222c9501b69af324ed1bdc04adefd3b17fabb59
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : dea163128c251d09872f2e929249a01f4c233666
This is a major API revision to replace the Python-like API with
something more idiomatically Rust. In particular you now create a
FirefoxRunner object and then call start() and end up with a
FirefoxProcess. This is pretty similar to the Command builder in std.
MozReview-Commit-ID: DmEfIfKSukA
--HG--
extra : rebase_source : 30fba6b2d9584a8a4128b641747beda1d264f7c5
This fixes all known issues with serialization and parsing of these two
properties, and in particular calc handling and such:
https://bugzilla.mozilla.org/show_bug.cgi?id=1434692https://bugzilla.mozilla.org/show_bug.cgi?id=1434724
Also does a fair amount of cleanup and all that, which was needed, this code
was a mess.
There are further cleanups that can be done, like renaming the
font-variation-settings animation stuff.
Source-Repo: https://github.com/servo/servo
Source-Revision: dcd13b857cc5085dcec5047433637af3d9013920
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 2162eb0164b4a05f33482417996dedf3ff74825d
OpenType font collections (*.ttc) contain multiple faces in a single file,
identified via index. When creating a font descriptor for a FreeType or
Fontconfig font, we mistakenly set the index to zero, always.
This bug became visible when layout and WebRender would disagree on the face in
use, rendering text with the metrics from the proper face but the outlines of
another. Unless, of course, the selected face was the first (or only) in the
font file.
MozReview-Commit-ID: 73qcPOD0HIr
--HG--
extra : rebase_source : b5784ff547bae99186d646dbb92b31660beb3970
Everything that needs them up-to-date will call flush appropriately, there
should be no need to do it manually.
This way we coalesce all the stylist updates until the next style flush in the
best case, or until one of the consumers actually needs them.
MozReview-Commit-ID: BVsxXxhtcKL
--HG--
extra : rebase_source : a41c14689fdcdb30935e16bdb0e757e7140e88e7
The prefs parser has two significant problems.
- It doesn't separate tokenizing from parsing.
- It is implemented as a loop around a big switch on a "current state"
variable.
As a result, it is hard to understand and modify, slower than it could be, and
in obscure cases (involving comments and whitespace) it fails to parse what
should be valid input.
This patch replaces it with a recursive descent parser (albeit one without any
recursion!) that has separate tokenization. The new parser is easier to
understand and modify, more correct, and has better error messages. It doesn't
do error recovery, but that would be much easier to add than in the old parser.
The new parser also runs about 1.9x faster than the existing parser. (As
measured by parsing greprefs.js's contents from memory 1000 times in
succession, omitting the prefs hash table construction. If the table
construction is included, it's about 1.6x faster.)
The new parser is slightly stricter than the old parser in a few ways.
- Disconcertingly, the old parser allowed arbitrary junk between prefs
(including at the start and end of the prefs file) so long as that junk
didn't include any of the following chars: '/', '#', 'u', 's', 'p'. I.e.
lines like these:
!foo@bar&pref("prefname", true);
ticky_pref("prefname", true); // missing 's' at start
User_pref("prefname", true); // should be 'u' at start
would all be treated the same as this:
pref("prefname", true);
The new parser disallows such junk because it isn't necessary and seems like
an unintentional botch by the old parser.
- The old parser allowed character 0x1a (SUB) between tokens and treated it
like '\n'.
The new parser does not allow this character. SUB was used to indicate
end-of-file (*not* end-of-line) in some old operating systems such as MS-DOS,
but this doesn't seem necessary today.
- The old parser tolerated (with a warning) invalid escape sequences within
string literals -- such as "\q" (not a valid escape) and "\x1" and "\u12"
(both of which have insufficient hex digits) -- accepting them literally.
The new parser does not tolerate invalid escape sequences because it doesn't
seem necessary and would complicate things.
- The old parser tolerated character 0x00 (NUL) within string literals; this is
dangerous because C++ code that manipulates string values with embedded NULs
will almost certainly consider those chars as end-of-string markers.
The new parser treats NUL chars as end-of-file, to avoid this danger and
because it facilitates a significant optimization (described within the
code).
- The old parser allowed integer literals to overflow, silently wrapping them.
The new parser treats integer overflow as a parse error. This seems better,
and it caught existing overflows of places.database.lastMaintenance, in
testing/profiles/prefs_general.js (bug 1424030) and
testing/talos/talos/config.py (bug 1434813).
The first of these changes meant that a couple of existing prefs with ";;" at
the end had to be changed (done in the preceding patch).
The minor increase in strictness shouldn't be a problem for default pref files
such as greprefs.js within the application (which we can modify), nor for
app-written prefs files such as prefs.js. It could affect user-written prefs
files such as user.js; the experience above suggests that integer overflow and
";;" are the most likely problems in practice. In my opinion, the risk here is
acceptable.
The new parser also does a better job of tracking line numbers because it (a)
treats "\r\n" sequences as a single end-of-line marker, and (a) pays attention
to end-of-line sequences within string literals.
Finally, the patch adds thorough tests of both valid and invalid syntax.
MozReview-Commit-ID: JD3beOQl4AJ
Marco Bonardo
Csoregi Natalia
Emilio Cobos Álvarez
Marco Castelluccio
Daniel Holbert
Jonathan Kew
Ryan Hunt
Gabriel Luong
Nathan Froyd
Jan de Mooij
Gian-Carlo Pascutto
Dylan Stokes
Gijs Kruitbosch
Narcis Beleuzu
Johann Hofmann
Luca Greco
Alessio Placitelli
Jonas Reinwald
Munro Mengjue Chiang
Bogdan Pozderca
Mauricio Collares
Jan Odvarko
James Graham
Martin Stransky
Anthony Ramine
Amit Kumar
Mathieu Leplatre
Jan Steffens
Brindusan Cristian
Nicholas Nethercote