This affects HTMLMediaElement, MediaRecorder and RTCPeerConnection, which are
the 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.
Depends on D87127
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
Being in gfx/layers/composite, AsyncCompositionManager.h does not
get to include CompositorBridgeParent.h (which is in gfx/layers/ipc)
as simply '#include "CompositorBridgeParent.h"'.
Differential Revision: https://phabricator.services.mozilla.com/D87665
We do the flex algorithm by assuming the available block-size is
unconstrained. Thus, we can remove `availableBSizeForContent` and
`aStatus` passing to DoFlexLayout(), ComputeMainSize(), and
ComputeCrossSize().
Differential Revision: https://phabricator.services.mozilla.com/D87109
Although this goes against the suggestion of the sample algorithm in the
spec, this brings the layout of the multi-line column-oriented flex
container in paginated context closer to the layout with no
fragmentation. This also matches Google Chrome's behavior.
Tweak flexbox-unbreakable-child-2.html so that it matches the rendering
as of this patch. Change the height of `.muticol` and the removal of
border in `flexContainer` to let two flex items fit exactly into the
flex container's height, making reference easier to write.
Differential Revision: https://phabricator.services.mozilla.com/D87107
This patch adds a createDefaultSettings() method to nsIPrinter to
initialize a default print settings object specific to that printer.
It implements the functionality for Linux and macOS but adds only stubs
for Windows.
Differential Revision: https://phabricator.services.mozilla.com/D87125
To ensure correct usage of TLSs in the profiler, they are now better encapsulated so that:
- init() is called once and its result is cached. (TLSREGISTEREDThread::Init() doesn't need proof of the PSLock, because it's using thread-safe function-static initializers.)
- get() and set() always init() as needed, or in some particular cases strongly assert that init() was successful.
Also, a null-check was missing in profiler_init_threadmanager().
Depends on D87588
Differential Revision: https://phabricator.services.mozilla.com/D87589
Assertions are also clarified with messages, to better distinguish the same tests in different locations.
Assertions should now cover all cases:
- NEW: After registering a thread in the profiler with `CorePS::AppendRegisteredThread`, the TLS should be set to that thread.
- NEW: If `profiler_register_thread` is called again, the TLS should still be set to that thread.
- When `profiler_unregister_thread` is first called, the TLS should still be set to that thread (that's the assertion currently trigering this bug 1657174),
- NEW: When `profiler_unregister_thread` is first called and after we remove the thread with `CorePS::RemoveRegisteredThread`, the TLS should now be null.
- If `profiler_unregister_thread` is called again (or with a never-registered thread), the TLS should be null.
This is a further exploratory patch for bug 1657174, this will not prevent crashes, but hopefully it should give a bit more information, at least a smaller range in which the possible presumed registration/TLS race happens.
Differential Revision: https://phabricator.services.mozilla.com/D87588
This change consists of;
1) Use switch statement for the given PrintPreview Navigation type.
2) Simply iterate over the children of nsPageSequenceFrame for
PRINTPREVIEW_GOTO_PAGENUM
3) Use GetCurrentSheetFrameAndPageNumber for PRINTPREVIEW_PREV_PAGE and
PRINTPREVIEW_NEXT_PAGE so that it should now match
printPreviewCurrentPageNumber
(that means the edge case where the current scroll position is in
the gap between pages has been fixed by this change)
4) Scroll to the position where the target frame is positioned at the center of
the print preview scroll port in the cases of PRINTPREVIEW_PREV_PAGE,
PRINTPREVIEW_NEXT_PAGE and PRINTPREVIEW_GOTO_PAGENUM
4) is a bit debatable but it can be now easily modified by changing
ComputeScrollPositionFrameAtCenter later if it turns out the current way is not
reasonable.
Differential Revision: https://phabricator.services.mozilla.com/D87548
So that we can keep using the logic in the old print preview UI.
For the new print preview UI, the original PrintPreviewScrollToPage will be
modified gradually in subsequent changes.
Differential Revision: https://phabricator.services.mozilla.com/D87543
Jean-Yves Avenard
Mark Striemer
Cosmin Sabou
Bogdan Tara
Tom Prince
Mike Hommey
Jan-Ivar Bruaroey
Andreas Pehrson
alwu
Botond Ballo
Agi Sferro
Ting-Yu Lin
Jeff Gilbert
Erik Nordin
Gijs Kruitbosch
Gerald Squelart
John Lin
Hiroyuki Ikezoe
James Teh