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
* The order-details container arranges and populates the items list and the 2nd total line under the items.
* The displayItems list is rendered into 2 lists, a "footer-items" list which displays tax and similar items just before the total, and a "main" list for everything else.
* The list items are instances of a payment-details-item component
* Initial layout of the line items and total with css grid
* Tests for order-details component
* Tests for payment-detail-item component
MozReview-Commit-ID: 68r8SSgwHgq
--HG--
extra : rebase_source : 8b2287124615bd4c16ab900d1f029d02538ccf1f
Download protection requires both the malware list as well as its
own special lists. The code therefore checks that both Safe
Browsing and download protection are enabled before checking
downloaded files.
The list manager should check the same prefs before downloading
any of the download protection lists in order to avoid connecting
to the Safe Browsing server when Safe Browsing is fully disabled.
MozReview-Commit-ID: 66vMA56T4pJ
--HG--
extra : rebase_source : cef14cf5a03290bd10d8d02367709e1ffd5e9030
Because of a small correction in how we measure this data,
I'd like to get more releases worth of information for this.
MozReview-Commit-ID: JAAsQly6Is8
--HG--
extra : rebase_source : 918591e48d2998af24af7e61ea9206e10bfc70c8
Followup on the previous commit, the same pattern occured in the Histograms section.
MozReview-Commit-ID: 41SiI1nBLSm
--HG--
extra : rebase_source : 2e642658c5721cab41f25c4a6c81f38390badef7
The "Keyed Histograms" category didn't alway have the "has-data" class although there were some data to display. "option" was compared to a string but it's a dom element, so its value should be compared instead.
MozReview-Commit-ID: 3eC0UPpJaNJ
--HG--
extra : rebase_source : 84e87676959008c4f884d171788682506ac11804
nsIDOMWindowUtils.sendKeyEvent() can dispatch any keyboard events, i.e.,
may dispatch different key events from actual Gecko's behavior. Instead,
they should use nsITextInputProcessor directly or synthesizeKey() of
EventUtils which wraps nsITextInputProcessor.
MozReview-Commit-ID: EDWqXy1OxJp
--HG--
extra : rebase_source : 158c6f3d1611646540133297e4c8352e0b85ab79
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 an existing overflow in testing/profiles/prefs_general.js, for
places.database.lastMaintenance (see bug 1424030).
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 ";;" is the most
likely problem 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: 8EYWH7KxGG
* * *
[mq]: win-fix
MozReview-Commit-ID: 91Bxjfghqfw
--HG--
extra : rebase_source : a8773413e5d68c33e4329df6819b6e1f82c22b85
This patch introduces a cache of blob urls which are related to the cssCode
injected by the extensions using tabs.insertCSS, which aims to reduce the
amount of memory used by the extensions to store the cssCode injected
into the tabs and their subframes in the content child process.
The generated Blob URL are associated to the extension principal,
so that it is easier to identify in the about:memory reports
which is extension that is using the cached data.
MozReview-Commit-ID: ERhR5nmVMqY
--HG--
extra : rebase_source : af8e2c3312c84bec6715158bcc8af82b76c8a8a6
This requires unlocking the unstable features in the rust compiler
by using RUSTC_BOOTSTRAP=1
MozReview-Commit-ID: 1uUG1Ekp1YH
--HG--
extra : rebase_source : d8a5aa5d13f3ee055de8a544b0d5ca8af0aab751
It's a minor change that should align us better with our selection of locales
(Services.intl will use user selection of regional preference locales).
I also removed the western arabic numeral system limitation to allow persian locales
to use eastern arabic numerals correctly.
MozReview-Commit-ID: 8TXX0X9RY9z
--HG--
extra : rebase_source : a7c8f507d841945e47f2d4cc142b4b05bbfab08f
Csoregi Natalia
Marco Castelluccio
Martin Stransky
Mathieu Leplatre
Narcis Beleuzu
Nicholas Nethercote
Servo VCS Sync
Kit Cambridge
Cameron McCormack
Cosmin Sabou
Sam Foster
Tom Ritter
Mike Cooper
Boris Zbarsky
Dave Townsend
Valentin Gosu
Noemi Erli
Edouard Oger
Francois Marier
Andreea Pavel
Mark Banner
Marco Bonardo
Johann Hofmann
Dão Gottwald
Jeremy Lempereur
Masayuki Nakano
shindli
Luca Greco
Bogdan Tara
Dorel Luca
Sebastian Hengst
Kartikaya Gupta
Andrew Swan
Shane Caraveo
arthur.iakab
Zibi Braniecki