Instead of something like
"ByteStringSequenceSequenceOrByteStringByteStringRecord" we should have
"(sequence<sequence<ByteString>> or record<ByteString, Bytestring>)" in error
messages.
Please take a careful look at the resulting error messages (see attachment
in the bug) to see whether this makes sense.
Differential Revision: https://phabricator.services.mozilla.com/D64890
--HG--
extra : moz-landing-system : lando
The BindingCallContext tracks what method the conversion is for, and the source
description is how the primitive is involved in that method (e.g. "argument 5").
Differential Revision: https://phabricator.services.mozilla.com/D64887
--HG--
extra : moz-landing-system : lando
We basically need this because some of the type conversions those guts need to
do may need a BindingCallContext.
We could probably do more optimization here to only generate the
BindingCallContext bits if we will really need them, more or less based on our
return type. But for now that doesn't seem worthwhile.
Differential Revision: https://phabricator.services.mozilla.com/D64886
--HG--
extra : moz-landing-system : lando
Dictionaries always need a BindingCallContext, because they can throw
MSG_NOT_DICTIONARY from Init().
We allow non-binding callsites to pass JSContext*, in which case they will not
get quite-as-nice error reporting.
Differential Revision: https://phabricator.services.mozilla.com/D64885
--HG--
extra : moz-landing-system : lando
We instantiate this class in various binding methods. Future patches will make
use of it to throw errors.
Differential Revision: https://phabricator.services.mozilla.com/D64883
--HG--
extra : moz-landing-system : lando
This does not change behavior at the moment, because the only callers of
ThrowErrorMessage that pass an error number that has a context pass an empty
string for the first (context) arg. Both of those callers are changed to pass
nullptr for the context in this patch.
We want to support nullptr to mean "empty context", because that way at
callsites we can avoid having extra empty strings.
We could avoid putting this machinery in place if we hardcoded the trailing
": " at all the callsites, but that would reduce future flexibility in where the
context is placed in the message string (e.g. if we wanted to move it to the
end instead of the beginning) and increase the amount of string data we have to
cart around in the binary quite noticeably: we have a _lot_ of places in
bindings where we call ThrowErrorMessage.
Differential Revision: https://phabricator.services.mozilla.com/D64882
--HG--
extra : moz-landing-system : lando
This is already done for the outer nsJAR, but it wasn't done for the inner nsJAR.
(The omnijar is a nested zip archive on Android: the outer archive is the APK and the inner is the omnijar file.)
So we were re-using the file mapping but not the result of the uncompression.
Differential Revision: https://phabricator.services.mozilla.com/D63970
--HG--
extra : moz-landing-system : lando
If we're in the middle of shutting down a content process, don't GC if we get a
memory pressure event. Shutting down the process is a better way to free memory!
This doesn't seem to happen much, presumably because once we've started
shutting down the content process we ignore new messages, like ones telling
us to do memory-pressure.
Differential Revision: https://phabricator.services.mozilla.com/D65755
--HG--
extra : moz-landing-system : lando
This is probably an old-ish bug made more frequent by the font loading
optimizations.
PostRebuildAllStyleData is a bit of a misnomer, but was always calling
ClearCachedData() on the style set, even if we weren't guaranteed to restyle
every element.
This means both wasted work and correctness issues (as the "uses <rare-feature>"
bits are cleared during this call, on the assumption that we'll then visit all
elements and that'd recompute it properly).
For now, unify a bit the different code paths and only clear these bits if we're
guaranteed to restyle all elements.
I should rename this to something better in a follow-up, and ideally also
decouple the ClearCachedData() calls a bit...
Differential Revision: https://phabricator.services.mozilla.com/D65740
--HG--
extra : moz-landing-system : lando
Apps targeting SDK 29 are not allowed to open /dev/ashmem directly, and
instead must use NDK functions. Those functions are only available in
SDK 26 and higher, so we need this shim to use the functions if they
are available, else fallback to opening /dev/ashmem directly.
Differential Revision: https://phabricator.services.mozilla.com/D61012
--HG--
extra : moz-landing-system : lando
Boris Zbarsky
Nan Jiang
Markus Stange
Andrew Osmond
Mike Hommey
Andrew McCreight
Sylvestre Ledru
Noemi Erli
Sebastian Streich
Harry Twyford
Michael Cooper
Csoregi Natalia
Arthur Iakab
Emilio Cobos Álvarez
James Willcox
Geoff Brown
Ehsan Akhgari
Dão Gottwald
Mike Shal