Avoid hitting the rather slow effective TLD service by caching results when
mapping URLs to their base domains. In testing the cache ranged from a 1:1 to
a 3:1 hit:miss ratio.
--HG--
extra : histedit_source : 9692a36bb32474b6de0a8291ceb9af7a19d221ff
We already periodically calculate the ghost window amount after cycle
collection, this just uses a cached value of that for the distinguished amount.
This avoids the overhead of a recalculating the value when reporting telemetry.
--HG--
extra : histedit_source : 4ba3ee62fd2871a87970faca8a70b2284e83981d%2C9246ac39cea50c3bb0d1693d8e831c3b3ad33ad9
After all the previous work, we can now base64 decode nsString types
without intermediate conversion steps to nsCString, which is faster and
more memory-efficient.
The current nsString decoding routine indirectly relies on the various
checks this routine performs; making it generic over string types
ensures that we can eventually call it directly from the nsString
decoding routine.
The existing Base64URL code converts from `const char` to `uint8_t`.
We're going to want versions that convert from character types to
character types, so make the decode routines accept generic input and
output types.
The decoding logic is the same for Base64 and Base64URL; we might as
well reuse the routines that we already have for Base64URL decoding so
we don't make mistakes in the logic.
These tables are nearly identical to the ones for base64url decoding,
but ideally will be slightly more readable, since things are broken up
into sets of eight entries at a time.
After all the previous work, we can base64 encoding nsString values
directly into nsString values, without having to go through intermediate
nsCString values. Since this routine backs base64 routines exposed to
the web, this change should help with OOMs that we see associated with
base64 encoding.
The nsACString -> nsACString encode routine has several checks in it for
correct operation, and the nsAString -> nsAString encode routine relies
on those checks happening via the nsACString -> nsACString routine.
Once we start encoding nsAStrings directly, we'll still need those
checks, and the easiest way to ensure they happen is to move the core
base64 encode logic for strings into a templated helper.
One less use of NSPR is a good thing. The failure cases that
PL_Base64Encode would have caught for us are:
1. "Truncation".
2. Integer overflow when computing destination string length.
3. Malloc failures.
The first one only gets checked if we pass in zero for the source
length, which we never do. The latter two only get checked if we pass
in a null pointer for the destination, which we never do. So removing
the error handling PL_Base64Encode implies here is a good thing.
Stylo's recent enabled-by-default behavior, combined with some Linux
distributions's packaging of LLVM separately from Clang, causes
confusion. To allay such confusion, rearrange the configure checks to
do two things:
1) Check for the clang binary prior to checking for clang's shared
libraries; it should be more obvious what you need to install from
an error about clang, and installing clang should pull in the
necessary clang libraries, avoiding the following scenario:
- run configure
- get error message about libclang
- install libclang
- run configure
- get error message about clang
2) Provide some context for what to do to avoid this error; the user may
not understand why we need a separate C/C++ compiler when they already
have a perfectly suitable one on their system.
1. Create a new test test_currency_amount_validation.html to test validation
with following scenarios
* test with well formed currency codes.
* test with invalid currency codes.
* test with valid lower case currency codes and check is it converted to
upper case.
* test with invalid currency codes while calling
PaymentRequestUpdateEvent::updateWith().
* test with invalid amount value with calling
PaymentRequestUpdateEvent::updateWith().
2. Move tests of test_validate_decimal_value.html to
test_currency_amount_validation.html
This patch implements currency validation algorithm according to the spec
https://w3c.github.io/payment-request/#validity-checkers.
1. amount.currencySystem must be "urn:iso:std:iso:4217".
2. amount.currency is valid with following criteria
1. The currency length must be 3.
2. The currency contains any character that must be in the range "A" to
"Z"(U+0041 to U+005A) or the range "a" to "z"(U+0061 to U+007A).
According to the spec, converting the currency to upper case and save it in
nsIPaymentRequest.
Asserts in MoveEmitterMIPS[32|64]::emitDoubleMove cause failures in some
tests, but they are redundant. The asserts check if the source or
destination register is scratch register, however scratch register is
actually used only for memory to memory move.
Instead, explicitly capture the frame tree state on the only caller that passes
this flag around.
This is somewhat wasteful if we end up reconstructing an ancestor frame, since
we'll capture state for it again. But we do that already in most of the cases
(somewhat inconsistently).
MozReview-Commit-ID: CUJsXaVoIpO
Signed-off-by: Emilio Cobos Álvarez <emilio@crisal.io>
We currently use the aFlags argument of ContentRemoved for two purposes:
(1) To determine when a frame is being removed due to its element being removed
from the DOM, so we reframe its now-possibly-no-longer-suppressed
whitespace siblings as needed.
In other cases, our ContentRemoved call will be followed by a
ContentInserted call, which will end up doing AddTextItemIfNeeded() to
generate the relevant textframes if they're necessary.
Since we only need to tell apart the "DOM removal" and "anything else"
cases, we don't need to thread the aFlags argument through all the ways
ContentRemoved can call itself (on an ancestor).
All those cases should just be treated as "not DOM removal". In particular,
even if the original call _was_ for a DOM removal, if we convert it to an
ancestor reframe, which will call ContentInserted on the ancestor as well,
we don't need to do anything with text siblings of the ancestor.
(2) To save the frame tree state from DestroyFramesFor, but the frame tree
state is unconditionally captured on RecreateFramesForContent, so we only
need to care about it in the original ContentRemoved call.
Because of that, we can move that to the callsite, patch incoming for that.
MozReview-Commit-ID: Gy5IhUysBlz
Signed-off-by: Emilio Cobos Álvarez <emilio@crisal.io>
Keyboard APZ dispatches an eVoidEvent to gather all event targets that a key event
would normally go to. This can sometimes trigger an HTMLInputElement to initialize its
editor, which can cause unnecessary DOM modifications.
MozReview-Commit-ID: 6EEttouVB81
--HG--
extra : rebase_source : e7ff9c50a13f43f66976e3f0294e3d1696b87169
When triggering an iframe load or starting to parse a document for an iframe, the main thread may often have some time before the new page has been created. Try to trigger CC/GC slice at such point in order to avoid collector later when page is already executing its JS
--HG--
extra : rebase_source : 806df0af1dbaefb1761134eca0bb7c6ade6ac1a9
This are some unit tests to track regressions in the environment
behavior exposed to embeddings for various javascript loaders inside
Gecko.
MozReview-Commit-ID: 8pn56Skwbat
Doing this avoids -Wundefined-var-template warnings with clang. This
warning is mostly harmless (clang is trying to tell you a linker error
might be awaiting you later), but being careful with this might make
using C++ modules easier somewhere down the line.
Eric Rahm
Bill McCloskey
Sebastian Hengst
Cosine
Ryan Hunt
Gabriel Luong
Michael Layzell
Nathan Froyd
Catalin Badea
Michael Kaply
Ben Kelly
Ryan VanderMeulen
Nils Ohlmeier [:drno]
Ehsan Akhgari
Eden Chuang
Jan Odvarko
Miran.Karic
Stone Shih
Emilio Cobos Álvarez
Jim Chen
Olli Pettay
Ted Campbell
Robert Strong
Tobias Schneider
Andrea Marchesini