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
Bug 1383896 added this constant to testing/talos/talos/config.py:
> FAR_IN_FUTURE = 7258114800
which is used as the value for the "places.database.lastMaintenance" pref.
(7258114800 seconds after 1970 is the start of the year 2200.)
libpref stores integers prefs as int32_t and the current parser doesn't detect
overflow. So this overflows to -1331819792. (I detected this with the new prefs
parser from bug 1423840, which does detect integer overflow.) As a result the
condition testing this pref in
toolkit/components/places/PlacesCategoriesStarter.js ends up always succeeding
in tests, which is the exact opposite of what was intended. This patch changes
it to 2147483647 (the year 2038), the maximum int32_t value.
(Note: this is much the same as bug 1424030, which was fixed recently.)
MozReview-Commit-ID: AQw4b8tmE9u
This fixes InspectorUtils::getCSSValuesForProperty to return the
correct values for line-style-type.
MozReview-Commit-ID: 72Tes6y15j8
--HG--
extra : rebase_source : fa893f59cafc433f554353cf42d0f9495cdd5b23
The invalid variable test for #if{,n}def was only checking that the
first character in the variable was alphanumeric or underscore, not
the other characters.
More generally, preprocessor instructions were also cut out such that
whitespaces before and after arguments were part of the arguments.
There's one place in layout/tools/reftest/manifest.jsm that was using
a broken pattern, making the test never true, which, once fixed, unveils
broken tests, so the branch that was never used is removed.
--HG--
extra : rebase_source : d1fe8a299203a29c0906ff99054c326acd135000
This will allow us to discard std hash map as a source of crashes.
Source-Repo: https://github.com/servo/servo
Source-Revision: e6d9c251d1b9770aa520bf358b79d906a00d71bb
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 3b5a6c2c7cd694eeeebc9c068a0add45545f0642
We no longer assert here when stylo-chrome is enabled.
MozReview-Commit-ID: CbVItBV2Q5V
--HG--
extra : source : 62d4361658b91c2825fae256913016495a9289f6
To avoid future issues, this is done by combining the Render and Update methods
into a single call. As a minor side-effect, timing in the parent method now
includes the time to run update.
MozReview-Commit-ID: GJ0l049eFRj
--HG--
extra : rebase_source : f9b4ee6f34bc45d87b3df40e5a25f3bfb2ec8068
The test only passes with WebRender enabled. Passing without WebRender
would require implementing CSS filters in the Gecko compositor.
MozReview-Commit-ID: HPgxxuj5iJl
--HG--
extra : rebase_source : 8afbc717d8e086f7a407eb5f0090f30d62d9638b
On a CLOSED TREE, since Android is barfing at the prefs key in the manifest:
runByManifest mode must be enabled to set the `prefs` key
MozReview-Commit-ID: 2oK3CG69s9E
CleanupFromTimeout is (transitively) recursing in calls to Close(), as that now leads to shutting down the plugin broker thread and CleanupFromTimeout was being rerun since nsThread::Shutdown runs tasks..
The Monitor's condition variable could be notified before the calling thread had begun to Wait for it. This caused the Notify to be missed, leading to hangs. By grabbing the Monitor in PostToDispatchHelper, we know Wait has been called because, otherwise, the calling thread would still hold the Monitor.
