(Instead of applying it directly to the menulist).
Since it's not inherited, we need to get the right value over to the scrollbox.
For that, export it from the arrowscrollbox, with the same name as the places
menupopup uses for the same purpose.
Differential Revision: https://phabricator.services.mozilla.com/D95887
This supports one manifestparser expression per line in the 'skip-if',
'fail-if' and 'run-if' keys. As a side effect the:
skip-if = foo ||
bar
syntax is no longer supported. Instead it can be:
skip-if =
foo # bug 123
bar # bug 456
Differential Revision: https://phabricator.services.mozilla.com/D95927
mIPCOpen would incorrectly be `true` before the actual IPC channel had been
opened. By instead using the IPC-provided CanSend() method, we can avoid this.
Differential Revision: https://phabricator.services.mozilla.com/D95890
Previously, it was possible to accidentally shut down a content process while it
was still launching if the process switch which requested the switch was
cancelled.
Differential Revision: https://phabricator.services.mozilla.com/D95889
Previously we would call RemoveFromList, without calling MarkAsDead, when
ShutDownProcess was called called from ContentParent::LaunchSubprocessResolve.
This tripped some assertions in BrowsingContextGroup's host code.
Differential Revision: https://phabricator.services.mozilla.com/D95888
This patch adds identifiers to existing log messages in the mic source and
AudioInputProcessing, and adds new log messages for complete tracing of frames.
Differential Revision: https://phabricator.services.mozilla.com/D95940
When opening a second input track, there will already be some data from its
first instantiation in the driver's scratch buffer. If we ignore this data, we
end up buffering too much in AudioInputProcessing::Pull and tripping an assert.
Differential Revision: https://phabricator.services.mozilla.com/D95939
Without this patch, AudioInputProcessing wouldn't be aware of an audio driver
changing to another driver, be it a system driver or an audio driver that starts
on its fallback.
It could fail an assert since neither of those new drivers would append any
input data, so AudioInputProcessing would run out of buffered data but not know
to reset the state doing the bookkeeping for this.
Differential Revision: https://phabricator.services.mozilla.com/D95938
With a dedicated MediaTrack subclass for microphone input we can now coordinate
appending real data and pulling silence in a single place. This makes it easier
to control the amount of buffering needed, and the timing expectations around
pulling silence.
All in all, we can remove most of the state for the assertions, and the complex
logic surrounding them.
Differential Revision: https://phabricator.services.mozilla.com/D95936
This was mainly driven by the need of querying this track for its channel count,
but it also moves us one usage away from SourceMediaTrack, which is a
longer-term goal (because of SourceMediaTrack::mMutex).
Differential Revision: https://phabricator.services.mozilla.com/D95934
When an AudioCallbackDriver starts a fallback SystemClockDriver is running in
its stead. The AudioTrack getting fed data from the input stream of the driver
will get real data while the AudioCallbackDriver is running, and silence while
the fallback driver is running.
If the MediaStreamTrack representing the microphone source is part of a
MediaStream being played by an HTMLMediaElement; and another MediaStreamTrack
representing another source with a lower channel count than the microphone is
part of another MediaStream being played by another HTMLMediaElement; then:
1. We start the graph with the other source's output channel count, and a
fallback driver.
2. Once the audio driver has started, it adds data at a higher channel count
than the graph's to its MediaTrack. The driver switches audio driver to
match the new channel count.
3. The new driver starts with a fallback driver, which adds silence to the
track. Silence has no channel count, so the graph sees only the channel
count of the other source and switches audio driver to match this.
4. Go to 1.
This patch fixes makes us memoize a previously returned max channel count for an
AudioSegment for use when there is only null data (e.g., silence) present in the
segment. This applies to step 3 above, where no audio driver would be switched
because the graph still sees the mic's channel count.
Differential Revision: https://phabricator.services.mozilla.com/D95931
XDRParserAtomTable and ParserAtomVector has the same content.
Removed XDRParserAtomTable and rewrote consumers to use ParserAtomVector.
Differential Revision: https://phabricator.services.mozilla.com/D95844
ParserAtomVectorBuilder is simplified version of ParserAtomsTable for XDR.
This doesn't perform deduplication, and just builds vector.
Differential Revision: https://phabricator.services.mozilla.com/D95843
Now ParserAtomsTable is part of CompilationState, or stack variable inside XDRStencilDecoder.
It's always created after CompilationInfo is stored into Rooted, and now
we don't have to worry about LifoAlloc pointer in move constructor.
Differential Revision: https://phabricator.services.mozilla.com/D95842
Later patch will move ParserAtomsTable field from CompilationStencil to CompilationState.
To simplify the change, add a reference for the CompilationStencil.parserAtoms in CompilationState.
The next patch will rewrite consumers to use the reference field.
Differential Revision: https://phabricator.services.mozilla.com/D95840
As a preparation to remove set from stencil, separate the deduplication part
and storage part of ParserAtomsTable.
The later patch will move HashMap out of stencil.
Differential Revision: https://phabricator.services.mozilla.com/D95839
Move the calculation of the dirty rects array earlier in frame
drawing, and supply that to the `start_compositing` method of
the compositor trait.
For now, it's assumed that the native compositor wants a single
dirty rect, and doesn't use buffer-age functionality. These
params will be configurable as part of the compositor capabilities
struct in follow up patches.
Differential Revision: https://phabricator.services.mozilla.com/D95828
This adds a pref containing a parent GUID, a lazy pref getter that validates
that GUID (asynchronously), and starts using the pref from the
PlacesCommandHook.
It also sets the future default (toolbar) into firefox.js, and overrides
that on the default branch when the new 2020 bookmarks pref is not set.
Finally, it sets the pref to the unfiled default for existing profiles
with a migration. If we end up delaying shipping, we'll need to
update that migration - but I don't see a way around that.
Differential Revision: https://phabricator.services.mozilla.com/D94500
This patch doesn't show the view options when right-clicking on folders or bookmarks within the toolbar, and also doesn't include an item to enter Customize mode to keep the menu from growing too large.
Differential Revision: https://phabricator.services.mozilla.com/D95798
I need this for some changes I want to make to Win32 file pickers.
* We add an event-driven variant to `mscom::AsyncInvoker`. When the async call
invokes `ISynchronize::Signal`, we post an event to the specified event
target (or implicitly to the main thread).
* For this to work, the async call needs to temporarily retain a reference to
itself, otherwise the async call object is destroyed and the in-flight call
is cancelled. This reference is stored in an "outer runnable" which is
responsible for executing the inner completion runnable, and then dropping
the self-reference.
* We only run the completion runnable upon *successful* initiation of the async
call. If there was a failure, we return that code immediately to the caller.
Failures also clear the reference to the completion runnable.
* If we could not obtain an async interface and must run synchronously, then
we run the completion runnable immediately after a successful synchronous
invocation.
Differential Revision: https://phabricator.services.mozilla.com/D95808