The change to throw NotSupportedError in AudioContext::CreateBuffer is
purposeful, to align with the spec and Chrome. There's apparently no web
platform test coverage for this, but we'll work on converting our test to a WPT.
The change to AudioContext::Close is fixing what looks like an obvious bug to
me (it _resolved_ a Promise<void> with a DOMException!). No obvious test coverage; https://bugzilla.mozilla.org/show_bug.cgi?id=1614960 tracks adding some.
The change to throw RangeError in OscillatorNode::Start is purposeful, to align
wih the spec and Chrome. Again, there's apparently no test coverage.
The change to throw RangeError in OscillatorNode::Stop is purposeful, to align
wih the spec and Chrome. Again, there's apparently no test coverage.
Differential Revision: https://phabricator.services.mozilla.com/D62141
--HG--
extra : moz-landing-system : lando
This is based on looking at what the actual spec constraints around the
channelCount, channelCountMode, and channelInterpretation setters are and on
testing Chrome's behavior: the setters _can_ be called as long as you do it with
the current value. That said, the spec sure could use being clearer here; the
style it's using is pretty hard to follow, unfortunately.
Differential Revision: https://phabricator.services.mozilla.com/D62140
--HG--
extra : moz-landing-system : lando
Patch to move all data members together at the start of the class and a couple of other minor tidyups.
Differential Revision: https://phabricator.services.mozilla.com/D62592
--HG--
extra : moz-landing-system : lando
This has been tightly coupled with script blockers, which are already being
used, for a while. This simplifies the situation, and avoids issues which can
occur when the script blocker for a document update has yet to be removed, but a
scriptrunner has.
Differential Revision: https://phabricator.services.mozilla.com/D62462
--HG--
extra : moz-landing-system : lando
These tests are all timing out in Firefox because we don't send either
a load or an error event for CSP-blocked loads. To work around this,
poll the iframe for the load, assuming it's complete when we see a
non-about:blank document with readyState complete (or an exception
from trying to access a cross-origin resource).
Differential Revision: https://phabricator.services.mozilla.com/D62447
--HG--
extra : moz-landing-system : lando
This patch implements osclientcerts for macOS.
Because the SDK we build with isn't recent enough, some of the functions we
need aren't guaranteed to be available. To handle this, we load the Security
framework at runtime and attempt to locate the symbols we need. If this
succeeds, then operation proceeds as normal. Otherwise, the module will report
that there are no certificates/keys available.
Differential Revision: https://phabricator.services.mozilla.com/D59957
--HG--
extra : moz-landing-system : lando
sThumbXXX in XInput is a short and its value range is between -32768 and 32767.
Differential Revision: https://phabricator.services.mozilla.com/D60876
--HG--
extra : moz-landing-system : lando
Without this we can run into stack overflows caused by unoptimized Rust
code.
Differential Revision: https://phabricator.services.mozilla.com/D62476
--HG--
extra : moz-landing-system : lando
This removes calling the initializer on the fog crate.
It leaves everything else in tact, including:
* Leaves the fog crate in tree, including its dependencies such as glean-preview
* Leaves the "fogotype" feature on gkrust-shared in place, ensuring glean is still compiled on nightly
* it's not used, so it should just get removed at link time
* Leaves the build config untouched (which sets the `MOZ_FOGOTYPE` definition)
Differential Revision: https://phabricator.services.mozilla.com/D62579
--HG--
extra : moz-landing-system : lando
Consistently use the relative path, with posix path separators, as the logging ID
used for tests and manifests.
Differential Revision: https://phabricator.services.mozilla.com/D62505
--HG--
extra : moz-landing-system : lando
Gets rid of `NS_NewThread`. Where it was used in testing, I gave the new named threads names relevant to their tests.
Differential Revision: https://phabricator.services.mozilla.com/D62475
--HG--
extra : source : 541b98270c9985c5bd3569ff3ff8bc6c3d3c650a
This patch adds a function to get an exported function in a remote process.
We need this implementation to address Bug 1604008, Bug 1608645, and Bug 1610790.
When `WindowsDllInterceptor` detours a function in a remote process, we used the
native `GetProcAddress` locally, and then detours the returned address in the
target process. The problem is if the caller's export table was modified, the
address returned from `GetProcAddress` might be invalid in the target process,
which is Bug 1604008.
I implemented `GetProcAddress` depending on both local and remote process image,
but it caused two regressions Bug 1608645 and Bug 1610790 because multiple
applications modify firefox's export table in multiple ways, such as replacing
an entry of EAT, replacing an RVA to Export section, or etc.
With this patch, we can use `PEExportSection<MMPolicy>::GetProcAddress` to get
an exported function in a remote process without relying on any local data so
that it's not impacted by modification of the local export table.
Differential Revision: https://phabricator.services.mozilla.com//D62315
Depends on D62314