There are some complications here to handle unpackaged and packaged
builds. In addition, there could be a difference between App prefs
and GRE prefs. Since the underlying backgroundtasks code is built as
part of Gecko (i.e., `toolkit/...` rather than `browser/...`) I have
favoured GRE prefs. I think, however, that what is written will work
for App-specific prefs, but I'm not concerned with that detail at this
time.
This also add tests for backgroundtask-specific prefs, which are
structured as both xpcshell and mochitest-chrome tests because
locally, the former tests unpackaged builds and the latter can
accommodate testing packaged builds. We could use mochitest-chrome
for both, but this has been pleasant to work with locally.
Differential Revision: https://phabricator.services.mozilla.com/D97510
This fix was written by looking at the stack trace from a fuzz bug. I could not reproduce the failure locally, but decoder has confirmed that this change fixes the problem.
If we bail out of Ion, then call ReportOverRecursed in `BailoutIonToBaseline` with a wasm frame on the stack, then while trying to capture the stack for the error, we assert while trying to construct a `JSJitFrameIter` using the constructor specialized for jit->wasm frames. The other `JSJitFrameIter` constructor has special handling for the `activation->bailoutData()` case, but the jit->wasm one just asserts that the activation doesn't have any bailout data.
Benjamin wrote this code and Luke reviewed it, and unfortunately neither of them are still around to answer questions. Reading through the patch history, I can't find any reason that the jit->wasm constructor doesn't support this case. It looks like we just assumed it couldn't happen, and our assumption would've been right if it weren't for stack overflow. Rewriting the jit->wasm constructor to use the same logic as the other constructor appears to fix the problem.
Differential Revision: https://phabricator.services.mozilla.com/D102826
I made sure that this didn't grow HTMLAnchorElement, though if we don't
care too much (sizeof(HTMLAnchorElement) is 176 right now) we might want
to remove ToSupportsDNSPrefetch and such.
This fixes a subtle bug where OnDNSPrefetchRequested wasn't being called
when IsNeckoChild was true.
Differential Revision: https://phabricator.services.mozilla.com/D103062
This patch is to add more profile markers to Talos tests, and improve existing ones, by grouping all Talos markers together under "Talos", using more descriptive labels, and employing interval markers where applicable.
Differential Revision: https://phabricator.services.mozilla.com/D98774
This test uses synthesizeNativeMouseMove to synthesize mouse events, the synthesized
native events would go through apz, so wait apz getting stable before starting test
to avoid possible timing problem that causes intermittent failure.
Differential Revision: https://phabricator.services.mozilla.com/D103192
Right now we don't store missing symbols when binary is missing for 64 bit platforms.
But some people don't need CFI to unwind stack since they've their own stuff but need to get symbol from address.
Differential Revision: https://phabricator.services.mozilla.com/D103152
I've tested this explicitly with `AppUpdateURL` because that's the
policy-controlled value we care about for the first use case for
background tasks, namely the background update agent.
Differential Revision: https://phabricator.services.mozilla.com/D99846
This adds a test to ensure that crash reporting works inside of
`application --backgroundtask ...` invocations. A test-only `crash`
task is added that uses `CrashTestUtils.jsm` to trigger a crash. The
`xpcshell` harness invokes that background task and processes any
minidump and extras just as it does for existing `xpcshell`
subprocesses.
The test is homed in `toolkit/crashreporter`, rather than in
`toolkit/components/backgroundtasks`, because there is special
handling for `CrashTestUtils.jsm` and the `testcrasher` library. It's
probably possible to make that infrastructure usable from multiple
locations but it seems low value.
Differential Revision: https://phabricator.services.mozilla.com/D98096
This establishes a high water mark for code loaded (even after a short
delay) by a background task that does nothing.
Code loaded here means:
1) Chrome JSMs imported using `ChromeUtils.import`;
2) XPCOM services, generally long-lived, loaded using `do_getService`
or `Services.*` or an equivalent;
3) XPCOM components defined in JavaScript and loaded via
`chrome.manifest` entries.
At this time background tasks do not load any of category 3. The
distinction is made because they are reported separately by Gecko.
This test is browser-chrome to make it easy/possible to work with
packaged builds.
Differential Revision: https://phabricator.services.mozilla.com/D98095
There are some complications here to handle unpackaged and packaged
builds. In addition, there could be a difference between App prefs
and GRE prefs. Since the underlying backgroundtasks code is built as
part of Gecko (i.e., `toolkit/...` rather than `browser/...`) I have
favoured GRE prefs. I think, however, that what is written will work
for App-specific prefs, but I'm not concerned with that detail at this
time.
This also add tests for backgroundtask-specific prefs, which are
structured as both xpcshell and mochitest-chrome tests because
locally, the former tests unpackaged builds and the latter can
accommodate testing packaged builds. We could use mochitest-chrome
for both, but this has been pleasant to work with locally.
Differential Revision: https://phabricator.services.mozilla.com/D97510
This will be useful for folding constant indexes to IntPtr in later patches.
Because we can't have different MConstant constructors with int64_t and intptr_t
arguments, reuse the one that takes int64_t by adding a MIRType argument to it.
Differential Revision: https://phabricator.services.mozilla.com/D102729
The alternative is to add support for MIRType::IntPtr to MSub and MMinMax which
seemed more complicated.
This also matches the IC code in EmitDataViewBoundsCheck. A later patch will
change codegen to branchSubPtr.
Depends on D102727
Differential Revision: https://phabricator.services.mozilla.com/D102728
This is the type that will be used to represent indexes/offsets into TypedArray
and DataView objects.
Depends on D102725
Differential Revision: https://phabricator.services.mozilla.com/D102726
This matches what we do for similar cases like MLoadUnboxedScalar.
A later patch will change the operand type to MIRType::IntPtr and that's easier
if there's no type policy to worry about.
Depends on D102724
Differential Revision: https://phabricator.services.mozilla.com/D102725
