I am not sure if you are okay with reviewing all those test changes.
Sadly it's not that easy to search through our huge JavaScript code
base for some generic name like 'isStrict'.
Differential Revision: https://phabricator.services.mozilla.com/D66573
--HG--
extra : moz-landing-system : lando
Dictionary iteration under Python 3 is in an inherently unpredictable order, and while we try to keep DEFINES ordered through the use of OrderedDicts, if at any point we populate DEFINES directly or indirectly while iterating through the contents of a non-ordered dictionary, the order of the DEFINES (and therefore the contents of the output Makefile) will be nondeterministic as well. This patch makes a number of changes to ensure that we only ever populate DEFINES in a deterministic fashion. (Note that in Python 3.7 and later, the built-in dict class actually has deterministic ordering, so these changes are technically only necessary until our minimum Python version becomes 3.7.)
Differential Revision: https://phabricator.services.mozilla.com/D66089
--HG--
extra : moz-landing-system : lando
We should throw a DOMException SyntaxError when setting pseudoElement a
syntactically invalid string or an unsupported pseudo.
Differential Revision: https://phabricator.services.mozilla.com/D66321
--HG--
extra : moz-landing-system : lando
Dictionary iteration under Python 3 is in an inherently unpredictable order, and while we try to keep DEFINES ordered through the use of OrderedDicts, if at any point we populate DEFINES directly or indirectly while iterating through the contents of a non-ordered dictionary, the order of the DEFINES (and therefore the contents of the output Makefile) will be nondeterministic as well. This patch makes a number of changes to ensure that we only ever populate DEFINES in a deterministic fashion. (Note that in Python 3.7 and later, the built-in dict class actually has deterministic ordering, so these changes are technically only necessary until our minimum Python version becomes 3.7.)
Differential Revision: https://phabricator.services.mozilla.com/D66089
--HG--
extra : moz-landing-system : lando
Callers should pass in UTF-8, since that's what the JS engine ends up with in the end anyway.
The various URL changes are because NS_NewURI converts incoming nsAString to
UTF-8 anyway. So we might as well do that up-front and then use the UTF-8
string for both the NS_NewURI call and the error-reporting if it fails.
Differential Revision: https://phabricator.services.mozilla.com/D65543
--HG--
extra : moz-landing-system : lando
CStringArrayAppender is just a copy of StringArrayAppender with the incoming
types expanded to accept both wide and narrow strings. Later patches will
remove the wide-string variants incrementally.
Differential Revision: https://phabricator.services.mozilla.com/D65537
--HG--
extra : moz-landing-system : lando
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
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
We don't really need the OOMReporterInstantiator bit. We can just use
FastErrorResult on the binding side, with casting to OOMReporter to ensure
callees take that, not an ErrorResult.
Differential Revision: https://phabricator.services.mozilla.com/D64184
--HG--
extra : moz-landing-system : lando
The callsite in DOMIntersectionObserver did end up throwing a RangeError, as the
spec requires, because in the end we just used the exception code to determine
the kind of exception to throw, but was misleading about what it was doing.
Differential Revision: https://phabricator.services.mozilla.com/D64175
--HG--
extra : moz-landing-system : lando
The method is exposed only if the consumer has the same principal as the PDF
would have if it were not getting the PDF viewer treatment.
The method just calls the print() method in the PDF viewer window.
It's enough to expose this on nsOuterWindowProxy, not RemoteOuterWindowProxy,
because PDF documents end up in the process they would have been in based on
their pre-PDF-viewer principal, since we do process determination in the parent
process but only run the pdfjs stream converter in the content process, once we
have decided which one to use.
Differential Revision: https://phabricator.services.mozilla.com/D63711
--HG--
extra : moz-landing-system : lando
Anthony Ramine
Marco Bonardo
Tom Schuster
Ricky Stewart
Narcis Beleuzu
Boris Chiou
Zibi Braniecki
Daniel Varga
Boris Zbarsky
Mark Banner
Arthur Iakab
Andrew McCreight
Ciure Andrei