They're enabled in all configurations and there's no plan to change
this. With it, dom.experimental_forms is also useless, so we can remove
it too.
Differential Revision: https://phabricator.services.mozilla.com/D87623
Some <dialog> related tests are failing on Beta because this
element is not enabled, enabling them to make the test pass.
Differential Revision: https://phabricator.services.mozilla.com/D87609
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