This affects HTMLMediaElement and MediaRecorder, which are the only implementors
of NotifyEnabledStateChanged.
This use case is going to become more common as users will be able to globally
mute cameras before requesting one. While muted, the camera is off and no frames
will flow. The old logic for showing disabled video tracks as black relied on a
frame appearing that could be turned black.
With this patch in this case we will create a frame if none has been seen yet,
and it will have a hardcoded size.
Differential Revision: https://phabricator.services.mozilla.com/D87128
This allows newly created window listeners, in MediaManager instances where the
cameras have already been muted, to get the right state.
Differential Revision: https://phabricator.services.mozilla.com/D87127
Previously it listened for them on main thread, as notified by the
MediaStreamTrack it was transmitting directly. With this patch it
listens for them through the TrackListener in the graph, and will
get notified when any track prior to the MediaStreamTrack's main
track in the graph changes enabled state as well.
Depends on D86926.
Differential Revision: https://phabricator.services.mozilla.com/D86931
Before this patch, re-enabling a camera track would first render an old frame
(from when it got disabled), then when the camera has started anew, render the
new frames.
With the patch, the black frame from disabling remains until the camera has
started and is sending new frames.
Differential Revision: https://phabricator.services.mozilla.com/D86926
This enables a use case where MediaManager disables a MediaStreamTrack's input
track, and all listeners of NotifyEnabledStateChanged on the MediaStreamTrack's
main track will get notified.
There can be 1 input track for N MediaStreamTracks, so this simplifies how many
tracks will need to be tracked by MediaManager and explicitly disabled in the
graph.
Depends on D86072
Differential Revision: https://phabricator.services.mozilla.com/D86925
Add UA (user agent) muting, a spec-supported feature that somewhat mirrors
track enabling/disabling, except only the browser controls it. The effect
on track sinks is additive: must be unmuted and enabled for there to be
output.
Fire mute/unmute events on JS, and observably set track.muted independent
of track.enabled (reusing existing infrastructure already in use by
RTCPeerConnection tracks).
Low-level: add mDeviceMuted and SetMutedFor() modeled after mDeviceEnabled
and SetEnabledFor() as parallel device state for both camera and microphone for
symmetry and maintenance.
High-level: Only expose messages to mute/unmute camera at the moment, since
that is what is immediately required for Android in bug 1564451.
Differential Revision: https://phabricator.services.mozilla.com/D84222
* New PrintSettingSelect element for the margin and color-mode picker
* The destination-picker and color-mode picker now extend the PrintSettingSelect
* Drive-by change to have numCopies info use the PrintSettingNumber for consistency & code reuse
* Margin presets are retrieved from a defaultSettings object which is the settings for the current printer without the user pref values
Differential Revision: https://phabricator.services.mozilla.com/D86849
With this patch a couple of changes are made to generally make it easier
to handle browsing contexts, and the current window. Basically this includes:
Since bug 1652932 landed the driver class keeps a reference
to the currently selected browsing context in content. As such
there is no need anymore to retrieve it from the framescript
each and every time. As side-effect this also removes the
async requirement and makes code better to read.
Similar handling for the browsing context exists for chrome scope,
which is also cached now, and no longer has to be retrieved via
the current window. With specifically this change "getCurrentURL"
for chrome scope correctly reports the location of the top-browsing
context, and not from the current one.
In the early days of Marionette a feature has been added to
work with embedded xul:browser elements. Those elemenets outside
of the tab browser have been tracked with "curFrame". Given that
until now there wasn't a single case to handle that, and the
code path is basically untested, it will be removed for now.
Differential Revision: https://phabricator.services.mozilla.com/D84707
Add test paintStatusReset() to ContentDelegateTest, which asserts that
onPaintStatusReset() is called after GeckoSession.setActive(false).
Add test capturePixelsSessionDeactivatedActivated() to ScreenshotTest, which
asserts that capturePixels() is successful if called when the session is
deactivated then reactivated, after waiting for the onPaintStatusReset() and
onFirstContentfulPaint() callbacks.
Differential Revision: https://phabricator.services.mozilla.com/D87463
Android-components listens to the GeckoView callback onFirstContentfulPaint to
track whether a contentful paint has occured, in order to decide when to
thumbnail a tab. Currently this gets fired once per tab.
However, when the GeckoSession is paused, we clear cached resources in the
compositor. This means that when the session is resumed, the compositor does not
have the necessary information to render the page (such as painted content
buffers, or the webrender display list). Because android-components attempts to
capture a new thumbnail immediately upon resuming, it ends up capturing a blank
thumbnail.
To fix this, add a new callback onPaintStatusReset() which is invoked when the
cached resources are cleared. Android-components can listen for this to be
informed when the contentful paint is no longer visible. It can then wait until
the subsequent contentful paint occurs before capturing the thumbnail.
Differential Revision: https://phabricator.services.mozilla.com/D87341
`mach create-mach-environment` is what installs `glean_sdk` to the `mach` `virtualenv`. `create-mach-environment` runs on the system Python and we can't assume the system Python has `glean_sdk` installed.
Differential Revision: https://phabricator.services.mozilla.com/D87507
We avoid going through Substring which imposes a limit on the string length of
INT32_MAX and failing a MOZ_RELEASE_ASSERT otherwise.
This adds a new `Base64EncodeAppend` function that takes 8-bit char input and
produces 16-bit char output, and appends to an existing string, which is what
we need here to avoid doing a large copy. Base64EncodeHelper is generalized
to accomodate for that.
So in addition to fixing the defect, this also optimizes performance and
memory usage.
Differential Revision: https://phabricator.services.mozilla.com/D87413
The internal Download API and the downloads API for extensions trigger
download requests on behalf of users. These should be considered
first-party requests, and therefore not be restricted by sameSite cookie
restrictions or tracking protection.
This patch has two components:
- Ensure that triggeringPrincipal is always the system principal, to
make sure that `BasePrincipal::IsThirdPartyChannel` returns false
when called by `CookieCommons::IsSameSiteForeign`.
The extension API implementation was the only consumer of the
Download API where triggeringPrincipal wasn't the system principal
(because loadingPrincipal is a moz-extension:-URI since bug 1579911).
- Set `channel.forceAllowThirdPartyCookie` to true, so that cookies are
always included in download requests even if the preference
`network.cookie.cookieBehavior` is 1 (aka BEHAVIOR_REJECT_FOREIGN).
Differential Revision: https://phabricator.services.mozilla.com/D87359
Jan-Ivar Bruaroey
Andreas Pehrson
Simon Giesecke
Severin
Sam Foster
Cosmin Sabou
Henrik Skupin
Mark Striemer
Gijs Kruitbosch
Tom Tung
Tim Huang
Agi Sferro
Michael Cooper
Tom Tung
Jan Varga
Jamie Nicol
longsonr
Julian Descottes
Dão Gottwald
Ricky Stewart
Narcis Beleuzu
pbz
Rob Wu
Sebastian Streich