`LLoadTypedArrayElementHole` used to need to a safepoint for a vm-call (bug 737783),
but this vm-call was later removed in bug 829896.
Differential Revision: https://phabricator.services.mozilla.com/D72643
The next part needs `ToBigIntPolicy` when storing BigInts into a typed array.
`MToBigInt` is currently only used as part of `ToBigIntPolicy`, therefore we
have to bailout for effectful operations, like `ToBigInt(object)`. Only strings
and booleans can be handled without a bailout.
Differential Revision: https://phabricator.services.mozilla.com/D72641
There are too few registers available on x86, therefore `LLoadTypedArrayElementHoleBigInt`
is reusing the ValueOperand's type register, similar to `CacheIRCompiler::emitLoadTypedElementResult`.
`LLoadUnboxedBigInt` and `LLoadTypedArrayElementHoleBigInt` are both using an OOL vm-call
if the result BigInt can't be allocated inline, similar to `CodeGenerator::visitInt64ToBigInt`.
Differential Revision: https://phabricator.services.mozilla.com/D72640
THis should continue allowing users to zoom out in RDM mode, or any time that
we are respecting the meta-viewport tag. It's only when we don't respect the
meta-viewport tag that we disable zooming out past initial zoom.
Differential Revision: https://phabricator.services.mozilla.com/D73461
This is a very first iteration of about:processes, so that people who actually need the tool can start using it immediately and provide feedback.
Differential Revision: https://phabricator.services.mozilla.com/D72617
Prior to this patch, PDF.js tracks both its own 'disabled' pref (which is used
by enterprise policy) and whether it is the default handler per the handler
service - but it tracks both in one bool, which determines whether its
streamconverter registers.
Really, what we want is to never use PDF.js if it's preffed off.
However, if there is some other default, it should be acceptable to use PDF.js
in some circumstances, like for <embed> or <object>s where otherwise we
would show no content at all.
Even for toplevel PDFs, if the user has configured Firefox to open PDFs in
an external helper app which is Firefox (which is currently an easy mistake
to make in the unknownContentType dialog), or has it set to the OS default,
but has changed their OS default to Firefox, we really still want to open
those PDFs with PDF.js.
This patch fixes all of this by splitting out the pref tracking from the
handler state tracking. Only the pref will completely disable PDF.js.
Then, in the streamconverter code, we check whether PDF.js should be used for
PDFs, and if there's a misconfiguration that we can correct. This code is
invoked from the parent process when we load PDFs in frames or toplevel
documents, and will prevent us from invoking PDF.js in the child if the user
would prefer that not to happen.
As a driveby, this cleans up how we track the pref inside PDF.js, and how we
get notified of changes to the handler - we were missing changes made in the
unknown content type dialog, so it seemed worth making it generic.
Differential Revision: https://phabricator.services.mozilla.com/D73510
This also renames `saveToDisk` to the more accurate `promptForSaveDestination`
given that it doesn't actually do the saving itself.
Differential Revision: https://phabricator.services.mozilla.com/D73507
This variant was only used for service workers' openWindow method, which has
been changed to no longer behave in this way, meaning that the type can be
removed. The follow-up simplification of removing
'ContentChild::ProvideWindowCommon', and moving the logic directly into
'BrowserChild' is not done in this bug, and will be done in a follow-up instead.
Differential Revision: https://phabricator.services.mozilla.com/D72935
The 'Id' variant was only used with b2g for remote `mozbrowser`s, and is no
longer relevant. The new code instead uses `PBrowser` directly in all cases.
Differential Revision: https://phabricator.services.mozilla.com/D72933
This patch asserts in various places that our LoadContext value on
BrowsingContext is consistent. This is done in order to get better diagnostics
for crashes such as those in bug 1629527.
Differential Revision: https://phabricator.services.mozilla.com/D72931
These two tests need to be updated to be aware of the new dotAll flag.
If we ever have to turn off the new engine, this patch should also be temporarily reverted.
Depends on D73118
Differential Revision: https://phabricator.services.mozilla.com/D73119
If a regular expression is too big, the assembler may fail with RegExpError::kTooLarge. When it does so, we want to throw an error: "regexp too big".
Until the most recent reimport of irregexp, we were actually reporting an OOM in these cases, because `CompilationResult::code` was default-constructed as an UndefinedValue and we took the "OOM in GetCode" path. Now `CompilationResult::code` is a Handle, so we crash if we try to access the value.
Making the situation slightly more complicated is the fact that we still have a macroassembler live, which means that we can't GC, which means that we can't report an error. The old code used an AutoSuppressGC for this (https://searchfox.org/mozilla-central/source/js/src/irregexp/RegExpEngine.cpp#1703), but that seems like an extremely blunt instrument.
Instead, I've refactored `CompilePattern` to call a separate `Assemble` function. This means that we clean up the macroassembler before we call `JS_ReportErrorASCII`. The new function is a straight copy-paste of the old code, except for error handling and `.` to `->` conversions for the values being passed by reference. Note that the order of checks has changed after calling `compiler->Assemble(...)`: now we check `result.Succeeded()` before examining `result.code`.
We also change the shared labels in SMRegExpMacroAssembler to be NonAssertingLabels. This suppresses assertions in the Label destructor that they are not used without being bound. The assertion is already suppressed for OOM (https://searchfox.org/mozilla-central/source/js/src/jit/Label.h#82-86), which is why we did not trigger it previously.
Differential Revision: https://phabricator.services.mozilla.com/D73758
There are a few changes here:
1. The code that used to be in wrapBody was moved to RegExpCompiler::PreprocessRegExp.
2. The `code` field in RegExpCompileData used to be a bare Object, and is now a Handle<Object>. (This makes named captures way easier to implement, because it lets us to allocate GC things while parsing a regexp without angering the hazard analysis.) I also took this opportunity to remove some dead code in the shim implementation of Handle.
3. Upstream V8 made a change to simplify the interface with the interpreter. Previously, the caller of IrregexpInterpreter::MatchForCallFromRuntime was responsible for allocating enough memory to hold both the capture results and the scratch registers. Now, the interpreter has the same interface as the compiler: the caller passes in a buffer large enough to hold the capture results, and the memory for the scratch registers is allocated internally. This requires a few small additions to the shim (IsInRange plus new methods on JSRegExp and SmallVector).
Depends on D73117
Differential Revision: https://phabricator.services.mozilla.com/D73118
This is as good a time as any to pull in some recent upstream changes (many of which I wrote). This patch was auto-generated using import-irregexp.py. The necessary changes to the shim code are in the next patch.
Depends on D73116
Differential Revision: https://phabricator.services.mozilla.com/D73117
Interpreted bytecode is ~3-5 times slower than compiled code, but ~5-10 times smaller. In general it seems like this is a good trade-off for the first few iterations, but for particularly long input strings this can cause a significant slowdown before we tier up. V8 eagerly tiers up to compiled code when the input string is 1000+ characters long. Following their lead on this fixes a significant regression in sunspider-regexp-dna.
Differential Revision: https://phabricator.services.mozilla.com/D73116
The engine supports parsing named captures, but we don't have the code in place to expose the captured groups. Until we do, this code will make sure that we get a syntax error when parsing them.
Differential Revision: https://phabricator.services.mozilla.com/D73115
If a look-behind back-reference succeeds, we have to subtract the length of the capture from the current position (so that the current position points to the beginning of the capture). We don't have the length in a register, so we have to read it from the capture registers, which are stored on the stack. However, we pushed the initial value of the current position, so the stack pointer is offset by one word from where we expect.
The fix is to pop the saved value *before* subtracting the length.
With this fix, we pass all the test262 tests for look-behind assertions, dotAll, and unicode property escapes. (I will turn them on in a separate bug.)
Depends on D73112
Differential Revision: https://phabricator.services.mozilla.com/D73113
This is very similar to wcosta's earlier patch, with a few adjustments to overcome
special cases:
- remove the wrench override of adb path; handle in config instead
- fix taskcluster config syntax in a couple of places
- add android-sdk-linux fetch for test-verify
Differential Revision: https://phabricator.services.mozilla.com/D73157
This adds a new property lsan-disabled to wpt metadata files, which takes
a boolean to determine if lsan should be entirely disabled for that directory.
Differential Revision: https://phabricator.services.mozilla.com/D73918
André Bargull
John Lin
Kartikaya Gupta
Matthew Gaudet
David Teller
Agi Sferro
Liang-Heng Chen
Gijs Kruitbosch
Dylan Roeh
Yura Zenevich
Greg V
Dale Harvey
Doug Thayer
Emilio Cobos Álvarez
Ricky Stewart
Marco Bonardo
Emily McDonough
Bogdan Tara
Daosheng Mu
Nika Layzell
Iain Ireland
Sebastian Hengst
Geoff Brown
James Graham