We add a [MOZ_CAN_RUN_SCRIPT_BOUNDARY] opt-out for now to keep the tree
compiling. The naming purposefully matches the C++ annotation that has a
similar effect, top make it easy to search for.
Differential Revision: https://phabricator.services.mozilla.com/D23520
--HG--
extra : moz-landing-system : lando
This allows calling a C++ MOZ_CAN_RUN_SCRIPT method that takes a callback argument.
The changes to TestCanRunScript.cpp are there to catch an incorrect change I was
going to make to the analysis to make this work, until I figured out that
RootedCallback should be MOZ_IS_SMARTPTR_TO_REFCOUNTED.
Differential Revision: https://phabricator.services.mozilla.com/D23519
--HG--
extra : moz-landing-system : lando
Since bug 1530324 removed the wrapper functions for async functions, it is no
longer true that a Debugger.Frame for an async function call calls its onPop
handler once after evaluating default arguments but before beginning execution
of the body.
Differential Revision: https://phabricator.services.mozilla.com/D23939
--HG--
extra : moz-landing-system : lando
When TalkBack receives a focus event, it redirects the accessibility focus (the green cursor) to the focused element. This is an important driver for the screen reader experience.
Since the focus mode of the GeckoView is "focusable in touch", the focused state of the view is very arbitrary when using TalkBack since the user never directly touches the view. The only way for the view to regain focus is if a control or link in the content is interacted with.
TalkBack user, who is explicitly interacting with the webview/geckoview would expect it to have focus, and to have the accessibility focus redirected in the page in the case of script-driven focus events.
Differential Revision: https://phabricator.services.mozilla.com/D23747
--HG--
extra : moz-landing-system : lando
This is more consistent with how it works in GeckoView. We need to give
up this behavior because it reset the top-level caret position on each
blur. This interferes with find in page which goes to the next search
result past the current caret.
Differential Revision: https://phabricator.services.mozilla.com/D23746
--HG--
extra : moz-landing-system : lando
This patch also base64-decodes the API inputs before storing in the DB in
anticipation of being able to pass binary data directly (bug 1535752).
This patch additionally whitelists the DB backing file in talos.
Differential Revision: https://phabricator.services.mozilla.com/D23430
--HG--
extra : moz-landing-system : lando
See https://bugs.llvm.org/show_bug.cgi?id=38944. clang thought it could safely leave out type information for some of our classes, but that information would have been helpful for debugging. The flag in this patch turns off the debug-info limiting.
Differential Revision: https://phabricator.services.mozilla.com/D24073
--HG--
extra : moz-landing-system : lando
This delivers a parsed and validated Web App Manifest to the
application, if present, during the page load process.
Differential Revision: https://phabricator.services.mozilla.com/D22612
--HG--
extra : moz-landing-system : lando
In bug 1501776, the `single_dep` and `multi_dep` schemas were aligned, which made both
branch in name_sanity identical. Simplify the code to reflect that.
Differential Revision: https://phabricator.services.mozilla.com/D24109
--HG--
extra : moz-landing-system : lando
do not attempt to parse XHRs as XML if content-length=0, to prevent logging "no root element found" errors
Differential Revision: https://phabricator.services.mozilla.com/D23444
--HG--
extra : moz-landing-system : lando
This patch adds support for scripted constructors, using the existing template object infrastructure.
Comparison points:
- BaselineCacheIRCompiler::createThis/updateReturnValue correspond to big "if (isConstructing) ..." blocks in ICCallScriptedCompiler::generateStubCode.
- CallIRGenerator::getTemplateObjectForScripted corresponds to the block in tryAttachCallStub starting with the comment "// Remember the template object ..."
Notes:
1. In the original CreateThis code, there was the following comment:
// Reload callee script. Note that a GC triggered by CreateThis may
// have destroyed the callee BaselineScript and IonScript. CreateThis
// is safely repeatable though, so in this case we just leave the stub
// frame and jump to the next stub.
This comment was out of date; as of bug 1415853, the code pointer is always valid. The comment does not exist in the new version.
2. Bug 870478 added code to the old version of |updateReturnValue| to load |this| from the baseline frame instead of the baseline stub frame, because we would not trace the copy of |this| if a rectifier frame was created. A better fix was delivered in bug 945275 (we now trace |this| in rectifier frames). The new version of |updateReturnValue| loads |this| out of the stub frame, because it is both easier to read and more efficient.
3. Unlike BaselineInspector::getTemplateObjectFor(Native|ClassHook), the scripted version does not use the callee as a guard to make sure that we have the correct template object. This is the same as the status quo. It works because we only retrieve the template object if the IC chain has exactly one non-fallback stub. We still store the callee in the metadata, because it is needed for BaselineInspector::getSingleCallee. This whole area of the BaselineInspector API should probably be redesigned, but it seemed out of scope for this patch.
Differential Revision: https://phabricator.services.mozilla.com/D22782
--HG--
extra : moz-landing-system : lando
This patch uses the infrastructure from the previous patch to add constructor support for native calls.
Comparison points:
- CallIRGenerator::getTemplateObjectForNative corresponds to GetTemplateObjectForNative in BaselineIC.cpp
Differential Revision: https://phabricator.services.mozilla.com/D22781
--HG--
extra : moz-landing-system : lando
Constructor stubs in the existing implementation contain template objects, which are unused by the stub itself but consumed by Ion. To make this work in CacheIR, this patch introduces meta ops, which generate no code but can be consumed by BaselineInspector.
This patch adds the infrastructure for meta ops and uses it to implement constructor class hooks, because it is a simple place to start. Subsequent patches add support for native constructor calls and scripted constructor calls.
In each case, BaselineInspector needs two pieces of information: a) The template object itself, and b) the callee, which BaselineInspector checks to make sure it is getting the correct template object. (The precise nature of the template object varies: it's a class pointer for hooks, but a pointer to the actual callee object for native and scripted constructors.) The meta op's arguments are a tag (in this case, "ClassTemplateObject") and two stub field offsets. NB: the class offset is reused from an earlier guard. To make this work, addStubField now returns the offset of the new field.
Other notes:
1. I changed an assertion in CompactBufferReader::seek to make it possible to seek directly to the end of the buffer. This is safe, because we already check to make sure we aren't at the end before reading from the buffer.
2. It turns out that the code to iterate through CacheIR bytecode is nicer if the CacheIR op table defines the length of the arguments to an op, without including the op itself. I made the change.
Comparison points:
- CallIRGenerator::getTemplateObjectForClassHook corresponds to GetTemplateObjectForClassHook in BaselineIC.cpp
Differential Revision: https://phabricator.services.mozilla.com/D22780
--HG--
extra : moz-landing-system : lando
This patch makes a couple of improvements to pushCallArguments, and one improvement to pushSpreadCallArguments.
1. The old code used two instructions to generate argPtr, where one instruction will do.
2. The old code jumped through some hoops to avoid adding |callee| and |this| to count before aligning the stack for jit frames. However, AlignJitStackBasedOnNArgs only cares whether nargs is even or odd. Since it doesn't make a difference whether we add 2 to nargs before or after alignment, this patch removes the "optimization".
3. The previous version of pushSpreadCallArguments used three instructions to find the end of the argument array, where one computeEffectiveAddress would do.
(It also improves the comments.)
Differential Revision: https://phabricator.services.mozilla.com/D22779
--HG--
extra : moz-landing-system : lando
This patch adds spread call support for scripted calls, native calls, and class hooks. (The old code did not have spread support for class hooks, but it's easy to add.)
Notes:
1. We don't support spread constructors yet. That will come later, after regular constructors are supported.
2. The old implementation called ICCallStubCompiler::guardSpreadCall to limit the size of the spread array. As an undocumented side-effect, guardSpreadCall also modifies the argc input register. The CacheIR version uses a fresh register, and relies on the magic of the CacheIR register allocator to preserve the input register.
Comparison points:
- GuardAndGetSpreadArgc corresponds to ICCallStubCompiler::guardSpreadCall.
- BaselineCacheIRCompiler::pushSpreadCallArguments corresponds to ICCallStubCompiler::pushSpreadCallArguments
- DoSpreadCallFallback is modified to correspond to DoCallFallback.
Differential Revision: https://phabricator.services.mozilla.com/D22778
--HG--
extra : moz-landing-system : lando
This patch implements class hooks in CacheIR. It only supports call hooks; constructor calls are handled in a later patch.
The implementation of class hooks overlaps almost completely with the implementation of native calls; the only difference is how we load the address of the callee.
Comparison points:
- The old logic is in TryAttachCallStub and ICCall_ClassHook::Compiler::generateStubCode.
Differential Revision: https://phabricator.services.mozilla.com/D22777
--HG--
extra : moz-landing-system : lando
This patch implements calls to native functions in CacheIR. Spread calls and constructor calls are handled in a later patch.
Notes:
1. This patch adds GuardFunctionHasJitEntry as a separate CacheIR op, which guards against relazification. The same functionality currently exists inside of ScriptedGetterResult. My original intent was to refactor ScriptedGetterResult to use the op, but if Ted's plans to add a delazification trampoline work out then the issue goes away entirely and we can just delete both versions of the code.
2. Like the callNative patch, this patch bakes argc into the stub code.
3. The existing code pops callee off the stack and unboxes it, immediately after copying the args. This doesn't make any sense, because we have already unboxed it once and it's still in a register.
4. There are a couple of places in tryAttachCallScripted where we want to decline to attach without counting it as a failure. Right now, if the CacheIR path fails, the old implementation will do the right thing for us. A future patch will add isTemporarilyUnoptimizable support to CallIRGenerator.
Comparison points:
- CallIRGenerator::tryAttachCallScripted and BaselineCacheIRCompiler::emitCallScriptedFunction correspond to TryAttachCallStub and ICCallScriptedCompiler::generateStubCode
Differential Revision: https://phabricator.services.mozilla.com/D22776
--HG--
extra : moz-landing-system : lando
Native calls in the simulator have to be redirected to a special swi instruction. In the old implementation, this redirection did not support calling the IgnoresReturnValue version of a native function. This patch fixes that problem in the new implementation.
Differential Revision: https://phabricator.services.mozilla.com/D22775
--HG--
extra : moz-landing-system : lando
This patch implements calls to native functions in CacheIR. Spread calls and constructor calls are handled in a later patch.
Notes:
1. When running in the simulator, native call stubs have an extra stub field to hold the redirected swi wrapper. We use some ugly ifdefs to make that work.
2. The simulator version of native call stubs also doesn't support ignoresReturnValue calls. This bug is fixed in a later patch.
3. pushCallArguments is based directly on the existing code. A later patch improves the comments and tightens up the generated code.
4. Compared to the previous implementation, this patch bakes argc into each stub (by using it to compute the address of |callee| in tryAttachCallNative). This increases the number of versions of the stub code we generate by some (hopefully small) factor. In a future patch (not yet written), this will be changed so that we unroll the loop in pushCallArguments for small argc, and share stub code for large argc.
Comparison points:
- BaselineCacheIRCompiler::pushCallArguments corresponds to ICCallStubCompiler::pushCallArguments
- CallIRGenerator::tryAttachCallNative and BaselineCacheIRCompiler::emitCallNativeFunction correspond to TryAttachCallStub and ICCall_Native::Compiler::generateStubCode. (The dividing line between the two functions is different between the old and new code, but aside from the exceptions detailed above the logic should be the same.)
Differential Revision: https://phabricator.services.mozilla.com/D22774
--HG--
extra : moz-landing-system : lando
