The standard for printf says that for integers, the result of converting
zero with an explicit precision of zero shall be no characters. But
flags and width still need to apply.
Differential Revision: https://phabricator.services.mozilla.com/D102696
%F and %G are the same as %f and %g, but using caps for the exponent
indicator, and for "inf"/"nan" for infinity and NaN.
%n$E is the same as %E, but taking the nth argument.
Differential Revision: https://phabricator.services.mozilla.com/D102695
ClearBeforePaint put the responsibility of clearing the current frame's DrawTarget
onto the widget. This doesn't compose well with WR RenderCompositor that may do
their own internal clearing. Instead, replace this with a GetTransparentRegion API
that can be used by RenderCompositors to limit where they clear so that they are
now fully responsible for clearing.
Differential Revision: https://phabricator.services.mozilla.com/D103253
GL_ARB_clear_texture implements some useful GL entry-points for clears
that can clear arbitrary sub-rects of the screen without having to latch
or disturb GL state. This refactors the glClear implementation to be in
terms of the provided glClearTexSubImage extension which is far more
flexible.
This further allows us to reuse clearing primitives in RenderCompositorSWGL
without having to use more expensive DrawTarget versions.
Differential Revision: https://phabricator.services.mozilla.com/D103252
This moves the exception prettifying to the script security manager for all JS
callers, where it is much cheaper and more consistently applied.
Differential Revision: https://phabricator.services.mozilla.com/D101492
It will mostly not be used. This patch just duplicates it in the two modules
that use it since it's not long for this world, anyway.
Differential Revision: https://phabricator.services.mozilla.com/D101491
Note that PromptUtils.objectToPropBag and the new propBagToObject function in
prompt_common.js do not do the recursive conversion that the BrowserUtils
versions attempted, but that code was completely broken, and would have failed
if it encountered a value which triggered recursion.
Differential Revision: https://phabricator.services.mozilla.com/D101481
Add missing conversion of max size constraints to device pixels in nsCocoaWindow::SetSizeConstraints() so that the maximum size constraints will be correct for windows that start off with a scaling factor not equal to 1.0.
Add back the fix for bug 1592416 to address scenarios where tooltips open on the wrong screen.
Differential Revision: https://phabricator.services.mozilla.com/D102798
This is not particularly efficient, and our non-native theme has
different paddings by default which causes test failures.
We could fix this with a bunch of other media queries, but it doesn't
seem worth it, other browsers don't do this, and we were already working
around it on mac anyways.
While at it, turn the border declaration into just `border-style`, which is
the only thing it's needed to override the `:hover:active` rule above. That
shouldn't have any behavior change.
Differential Revision: https://phabricator.services.mozilla.com/D103143
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 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
Mike Hommey
Lee Salzman
Emilio Cobos Álvarez
Emma Malysz
Butkovits Atila
Kris Maglione
Haik Aftandilian
Andreea Pavel
Jonathan Kew
Nick Alexander
Dave Townsend
Joan Jennings
Iain Ireland
Kimberly Sereduck
Kershaw Chang