Bug 1699224 - Part 2. Expose SharedMemoryBasic::Unmap for use by callers. r=jld This patch exposes SharedMemoryBasic::Unmap for use by callers to allow one to unmap memory out of our address space without destroying the SharedMemoryBasic object itself. This will be used by later patches in this series. Differential Revision: https://phabricator.services.mozilla.com/D109438

Bug 1699224 - Part 1. Ensure we map/unmap surfaces used by DrawTargetSkia. r=jrmuizel Since we want to be able to unmap shared surfaces which are not in use, we need to be able to map the data in as required. Blob images can access shared surfaces via recordings which are used by DrawTargetSkia. This patch makes it call Map/Unmap for data surfaces that require a data pointer in Skia. Differential Revision: https://phabricator.services.mozilla.com/D109437

Backed out changeset 120d1b7f97d0 (bug 1692018) for casuing failures on browser_search_discovery.js. CLOSED TREE

Bug 1700449 - Intermittent browser/components/urlbar/tests/browser/browser_quicksuggest.js r=mak Differential Revision: https://phabricator.services.mozilla.com/D109617

Bug 1700954 - Remove unused BinAST tests. r=arai Depends on D109765 Differential Revision: https://phabricator.services.mozilla.com/D109766

Bug 1700954 - Remove remaining BinAST fragments from ScriptLoader. r=arai,hsivonen,necko-reviewers Differential Revision: https://phabricator.services.mozilla.com/D109765

Bug 1699761 - Keep backwards compatibility with old recipe types r=k88hudson Differential Revision: https://phabricator.services.mozilla.com/D109878

Bug 1691579 - [devtools] Enable browser_spectrum.js on Fission. r=jdescottes. The test failure doesn't seem to have anything to do with Fission, but this might have introduce some changes in timings that would trigger a race condition somehow. The test was failing because in one of the test we were moving a slider to change a color, while the slider element had a height of 0, which would interfere with the computations that are done later. This patch adds a helper function to create the Spectrum widget, wait for the slider to have a non-zero height and then calling `show` (where some dimensions are being cached). Differential Revision: https://phabricator.services.mozilla.com/D109876

Bug 1676441 - Bounds checking for 4GB heaps. r=rhunt Add wasmBoundsCheck64() APIs that will take a 64-bit index and 64-bit limit, to be used on all 64-bit platforms. Document their use. Use the new 64-bit API on 64-bit systems (after widening the index appropriately) and the 32-bit API on 32-bit systems. Update both Baseline and Ion to handle this. Make a special exception for asm.js, which continues to use 32-bit bounds checking even on 64-bit systems. Continue to use the 32-bit API when heaps are known not to be 4GB exactly, so as to avoid some manipulation of the index value during bounds checking. Differential Revision: https://phabricator.services.mozilla.com/D99098

Bug 1676441 - Allow 64K pages. r=rhunt Increase the max number of allocatable pages on 64-bit from 65534 to 65536, except when Cranelift is present (because Cranelift depends on the bounds check limit being 32 bits and we don't want to deal with updating Cranelift right now). (An alternative to using ENABLE_WASM_CRANELIFT would be to introduce another name, ENABLE_WASM_65534 as a strawman, that is used throughout for clarity, and is defined by moz.configure when Cranelift is selected. Yet another alternative would be to limit Cranelift to 2GB heaps, to reduce the number of testing configurations. Discuss.) Change TlsData::boundsCheckLimit from uint32_t to uintptr_t, so that it can be 64 bits on 64-bit systems and can represent a 4GB heapsize. Update test cases so that boundary conditions are handled properly, for example, i32(65536*65536) == 0, so some test cases should not be run unless the max page count is below 64K. Note, this patch does *not* update the compilers, so the bounds check limit continues to be read as a 32-bit quantity. This results in some failures, which go away when the compilers are updated (next patch). Differential Revision: https://phabricator.services.mozilla.com/D108613

Bug 1692018 - Remove support for installing OpenSearch engines via ftp r=Standard8 Differential Revision: https://phabricator.services.mozilla.com/D107790

Backed out changeset 153bb20062aa (bug 1433500) for causing failure on test_captive_portal_service.js. CLOSED TREE

Bug 1700982 - [telemetry-tests-client] Allow newer versions of requests in harness; r=chutten Differential Revision: https://phabricator.services.mozilla.com/D109749

Bug 1697771, in cross origin test mode, the test test_autocomplete_https_downgrade.html should not have the passwords filled in, r=sfoster Differential Revision: https://phabricator.services.mozilla.com/D108795

Bug 1433500 - detectportal.firefox.com should return something informative for users r=nhnt11 This change constitutes a way we can redirect users to an actual page that explains what captive portals are and why we are making these requests. Normally users should not see this page, as we only compare the contents of a small html file. The meta redirect only happens when loaded in a page. The SUMO URL https://support.mozilla.org/kb/captive-portal will automatically redirect to the appropriate locale. Differential Revision: https://phabricator.services.mozilla.com/D99773

Bug 1700309 - Retry DNS query when RESOLVE_IP_HINT is set r=necko-reviewers,dragana Differential Revision: https://phabricator.services.mozilla.com/D109819

Bug 1700948 - Also run all wasm tests explicitly with `--wasm-compiler=ion`. r=lth. Now that we have Ion support for wasm on all Tier-1 targets, it's important to ensure that wasm tests are always run on Ion. That won't necessarily happen in the situation that wasm via Cranelift is also supported in the build, because optimising wasm compilation might be routed via Cranelift instead. Hence, to guarantee test coverage of Ion, we need to add test-also=--wasm-compiler=ion to all of the directives.txt files in jit-test/tests/wasm. Depends on D109860 Differential Revision: https://phabricator.services.mozilla.com/D109861

Bug 1685268 - [devtools] Enable Stylesheet resource server support for content toolbox. r=ochameau Enabling the support for stylesheet resources highlighted some issue with the current situation. A couple server tests needed to instantiate a resource watcher to pass. We also add a test case for link from inspector to stylesheet when doing a same process navigation (we already had one for target switching). Differential Revision: https://phabricator.services.mozilla.com/D106081

Bug 1685268 - [devtools] Don't clear StyleEditor UI on redundant dom-loading event. r=jdescottes,ochameau. With the previous patches in this queue, it looks like the timing is stlightly modified, and on initial load we can reveive stylesheet resources _before_ the intial dom-loading event. Since we're using dom-loading to clear the UI, we might destroy stylesheets that we shouldn't. We fix that in 2 folds: - clear the UI in onTargetAvailable, which we do receive before any resources - add a flag to the `dom-loading` resource when we're already going to be triggering onTargetAvailable for a given interaction (toolbox opening, cross-process navigation or any navigation when target will follow the global lifecycle). Differential Revision: https://phabricator.services.mozilla.com/D109471

Bug 1685268 - [devtools] Watch for stylesheet resources from inspector front instead of inspector panel. r=ochameau. This was previously done in the inspector panel initialization phase, after the inspector front was created, which could lead to races. Since the pageStyle actor requires stylesheets to being watched (when watcher support is enabled), we do this in the inspector front, before creating the page style actor. We put the resourceWatcher instance on targetFront from resourceWatcher#_onTargetAvailable so we can use it from everywhere. Differential Revision: https://phabricator.services.mozilla.com/D109470