Since stdout is being piped, redirecting stderr to stdout causes it
to end up in the same pipe interleaved, which is what we want.
Also added a non-zero return code to be set when there is no test output.
Differential Revision: https://phabricator.services.mozilla.com/D138481
Improved keyboard and screen reader accessibility for video closed captions menu by adding ARIA attributes, keyboard arrow navigation, and focus behavior to take the user into and out of the CC menu as it opens and closes.
Differential Revision: https://phabricator.services.mozilla.com/D136280
The audio processing configurations should be set before starting audio
device and audio processing, which requires to know the channel-count
requested from user and then initializes the audio processing settings
based on the channel count.
Depends on D136921
Differential Revision: https://phabricator.services.mozilla.com/D136922
The `NotifyInputData` has been removed in bug 1741959. Now the
`mRequestedInputChannelCount` is totally unrelated with it.
Depends on D136920
Differential Revision: https://phabricator.services.mozilla.com/D136921
In the current design, the `SetPassThrough` can start the initial step
for audio-processing, which requires to know the channel-count requested
by the users, so it's better to set the channel-count before setting the
pass-through to prevent from using an incorrect channel-count value.
Depends on D136919
Differential Revision: https://phabricator.services.mozilla.com/D136920
`MediaEngineWebRTCMicrophoneSource` doesn't need to know `APM`. The
`AudioInputProcessing` takes care of the audio processing provided by
libwebrtc.
Depends on D136796
Differential Revision: https://phabricator.services.mozilla.com/D136919
We are going to call `AudioInputProcessing::SetRequestInputChannelCount`
in the following patch (D136922 in bug 1751963), which will call
`MediaTrackGraphImpl::ReevaluateInputDevice`, via
`MediaEngineWebRTCMicrophoneSource::ApplySettings` before starting the
`AudioInputProcessing` and creating an `AudioCallbackDriver` in
`MediaTrackGraph`. It makes sure the input-channel count meets the current
user preference before starting the audio device and the audio
processing. However, if the current `GraphDriver` is not a
`AudioCallbackDriver` when `ReevaluateInputDevice` is called, we will hit
an assertion. To allow setting the correct input-channel count before
starting the audio device, we need to replace the assertion to an if
statement.
Differential Revision: https://phabricator.services.mozilla.com/D136795
I caught this locally on Android, c.mDuration was 104517 (which is more than two
seconds at the rate it was), it was overflowing uint32_t because we want to do
this in integers so the multiplication is big. The alternative is to make the
computation in floating point, rounding up so that there's enough space in the
buffer.
Now I wonder why we have such a big segment sometimes, and only on some OSes, but
we can investigate this later.
Differential Revision: https://phabricator.services.mozilla.com/D138303
These assertions are already diagnostic asserts, and this will make
failures to check Maybe into safe crashes rather than security bugs on
all branches.
A failure to check Maybe is more dangerous than a null pointer
dereference, as the generated code will produce a valid reference to
uninitialized data rather than a null reference which should safely
segfault.
Differential Revision: https://phabricator.services.mozilla.com/D138208
resistFingerprinting used to be set for the whole test but was changed to consider cases where it is unset. In those cases, pluginsLength and mimeTypesLength tests were only passing because there were no plugins installed and, later, no plugins were permitted. We now hardcode some fixed PDF entries so the test has to consider that.
Depends on D133291
Differential Revision: https://phabricator.services.mozilla.com/D138497
Most of the support for presenting a WebGLFramebuffer to a swap chain existed as part of the
mechanism for opaque WebXR framebuffer support. However, such "opaque" framebuffer are meant
to be opaque in the sense that their attachments can't be inspected or changed, which does
not provide the requisite level of control for efficiently implementing Canvas2D snapshots.
To this end, the existing Present mechanism is slightly extended to allow presenting to the
swap chain already present in WebGLFramebuffer without the existence of a corresponding
MozFramebuffer.
This also fixes a bug in that AsWebgl() was no longer being utilized in CanvasRenderer, such
that a new mechanism that routed GetFrontBuffer() was needed to fix the code rot.
There are also some efforts to remove a couple redundant copies I noticed in profiles along
the way.
Differential Revision: https://phabricator.services.mozilla.com/D138119
Now that each DrawTargetWebgl shares the same WebGL context, we can efficiently draw snapshots
of one DrawTargetWebgl to another without requiring any readback or error-prone driver-provided
shared context/resource mechanism. We just need to simply pass the WebGL texture from one target
to the other, and use it like any other texture.
This provides SourceSurfaceWebgl to store and pass along that WebGL texture. It is largely
modeled off of SourceSurfaceSkia in terms of its copy-on-write behavior. There are three
noteworthy state changes that it must track from DrawTargetWebgl - when the framebuffer
contents is changing, when the framebuffer is being destroyed, and when any cached texture
handle separate from a framebuffer is also being destroyed. It will copy, orphan, or read
back data as appropriate to handle each case.
If it needs to be mapped, it just forces a read back of the data into a CPU surface that
can be mapped as requested.
Differential Revision: https://phabricator.services.mozilla.com/D138118
Within DrawTargetWebgl, this implements a SharedContext class to store both the WebGL context and
also related resources for drawing with it. Not a lot of new code has actually been added as this
was mostly accomplished by refactoring as much drawing code as possible that touched the WebGL
context to be moved into SharedContext, while leaving any code that was only dealing with Skia
software rasterization still within DrawTargetWebgl itself as well as individual framebuffer state
that is unique to each DrawTargetWebgl instance.
Before DrawTargetWebgl can use SharedContext to draw, it must use SetTarget to install its framebuffer
as the one that the WebGL context will draw to as well as to learn details about the viewport and
other per-framebuffer state. All of the high-level cache state that was previously on DrawTargetWebgl
has now moved into SharedContext, so that SharedContext can easily access this for drawing as well
as to provide for the goal of simplifying resource limiting.
Differential Revision: https://phabricator.services.mozilla.com/D138117
This also disables smooth scrolling in the interaction tests. When smooth scrolling
is enabled a single scroll, say by pressing the down arrow, actually scrolls in
a number of steps starting small, increasing then decreasing. Because we only
wait for a single scroll event to fire before the test switches pages we only
capture the scrolling distance from the very first step which is often small and
sometimes turns out to be 0. Disabling smooth scrolling makes the scroll happen
in one operation so we capture the entire scrolling distance.
Differential Revision: https://phabricator.services.mozilla.com/D138295
