I don't think we want to keep the ugly widget hacks forever. Let me know if
you'd rather keep the property behind a pref but I don't think there's a point
in doing that.
Differential Revision: https://phabricator.services.mozilla.com/D62649
--HG--
extra : moz-landing-system : lando
When a page navigates away for example after a refresh, the collection of MediaDevices instance can take several seconds. If MediaManager is alive and a device change event arrives in it, the active instance of MediaDevices will be notified. Currently, the notification assert-crash when the window is not valid anymore. However, this is a valid scenario and depends on the cycle collection timing so the assert can be removed and the notification event can abort early and do nothing.
Differential Revision: https://phabricator.services.mozilla.com/D63312
--HG--
extra : moz-landing-system : lando
I don't think we want to keep the ugly widget hacks forever. Let me know if
you'd rather keep the property behind a pref but I don't think there's a point
in doing that.
Differential Revision: https://phabricator.services.mozilla.com/D62649
--HG--
extra : moz-landing-system : lando
Continuing on the trend of having all of the gpu data encoding in gpu_types.rs so that it is easy to find and to avoid repeating it in batch.rs.
Depends on D62928
Differential Revision: https://phabricator.services.mozilla.com/D63178
--HG--
extra : moz-landing-system : lando
A quality-of-life improvement that will make it easier to change the encoding of the user data without having to repeat the correct casting, bit shifting and masking in many places. It also makes it harder to encode the data incorrectly by mistake or forget information.
Differential Revision: https://phabricator.services.mozilla.com/D62928
--HG--
extra : moz-landing-system : lando
In `MediaManager::DeviceListChanged()` we check if a device is removed in order to stop it. That eventually will send the end track event. For doing that correctly the `mDeviceIDs` must be up to date. The `mDeviceIDs` is set as a part of gUM execution in `MediaManager::EnumerateDevicesImpl` inside an if-check. However, having the if-check is not necessary anymore. First, because the device ids do not contain anymore the "default:" prefix and second because there is no real reason to differentiate real from fake devices. In addition to that the if check had an error and did not update the `mDeviceIDs` correctly on video-only or audio-only gUM requests.
Depends on D63100
Differential Revision: https://phabricator.services.mozilla.com/D63204
--HG--
extra : moz-landing-system : lando
When structured clone reads a SAB and creates a new SAB object, or
when it serializes a SAB onto a channel, call a callback that lets the
embedder know. The embedder can then adjust its policy. Concretely,
we want to allow the browser to serialize threads in a process that
uses JS shared memory.
Note, for WebAssembly.Memory, reading and writing are delegated to the
cloning operations for SAB, so no special handling is needed.
Differential Revision: https://phabricator.services.mozilla.com/D61455
--HG--
extra : moz-landing-system : lando
In order to stop the SourceListeners, first collect them in an array and stop them outside the loop. The `StopRawID` method modifies indirectly the mActiveWindows and will assert-carsh since the iterator is active and the table is enumerated.
Differential Revision: https://phabricator.services.mozilla.com/D63100
--HG--
extra : moz-landing-system : lando
The existing check comparing toolbox's targets is racy.
The target may be updated late, after we compare them in this test.
Comparing PIDs looks safer as they should be updated almost immediately.
Differential Revision: https://phabricator.services.mozilla.com/D63176
--HG--
extra : moz-landing-system : lando
We do not want explicitly-returned completion values to cause later hooks
to be skipped, because consumers of the Debugger API need to be confident that
their code will not be silently skipped because some entirely unrelated
code instructed the debuggee to throw/return/terminate.
Differential Revision: https://phabricator.services.mozilla.com/D58187
--HG--
extra : moz-landing-system : lando
We want each hook to run in sequence, and we do not want the failure of one
hook to cause later hooks to skip execution. Doing so would make it difficult
for consumers of the Debugger API to be confident that their hooks will be
consistently executed, since entirely independent code could otherwise cause
their logic to be silently skipped.
Differential Revision: https://phabricator.services.mozilla.com/D58186
--HG--
extra : moz-landing-system : lando
Our goal is to guarantee that each hook observes the same state of the
debuggee itself unless explicit action is taken to change debugee state.
By passing this value along as we have been doing until now, we make it
impossible for later hooks to see the actual return value that the debuggee
code returned, which could be quite frustrating for debugger.
Differential Revision: https://phabricator.services.mozilla.com/D58185
--HG--
extra : moz-landing-system : lando
Just a quick cleanup. There's no reason for this value to be pulled into the
completion and then back out again right away. It is much simplier to access
the generator directly.
Differential Revision: https://phabricator.services.mozilla.com/D58182
--HG--
extra : moz-landing-system : lando
Switching the hook-dispatching logic to use the common bool-returning result
value allows us to easily centralize error reporting and debugger-realm-enter
such that we don't need to worry so much about how the error is handled.
Differential Revision: https://phabricator.services.mozilla.com/D57938
--HG--
extra : moz-landing-system : lando
Moving the location that the values are wrapped allows us to remove the need
for Maybe<AutoRealm> in favor of a normal RAII AutoRealm, which makes it much
easier to follow what realm is currently active.
Differential Revision: https://phabricator.services.mozilla.com/D57932
--HG--
extra : moz-landing-system : lando
This changes processHandlerResult to use the common bool-returning approach
used elsewhere in the codebase, which helps to simplify a lot of the code
because we can cleanly separate errors from explicitly-requested ResumeMode
values.
Differential Revision: https://phabricator.services.mozilla.com/D57931
--HG--
extra : moz-landing-system : lando
This avoids duplicating logic between processParsedHandlerResult and
processHandlerResult since both are quite similar.
Differential Revision: https://phabricator.services.mozilla.com/D57930
--HG--
extra : moz-landing-system : lando