Add a new preference, clibboard.plainTextOnly.
1. On: we only support kUnicodeMIME in SetData/GetData.
2. Off: we can support different MIME types in SetData/GetData
BTW, "copy image" is dependent on non-text/rich text support, so this
menu item is also disabled after we turn the pref off.
The owl.mp3 file and derivative is made of 128 0.026122s long samples , which gives us an actual duration of 3.343616s. However, when decoding those files, the first two samples are dropped by the CoreAudio and WMF decoder giving us an actual play time of 3.29s.
We have no way to determine the exact duration at the demuxing stage. External readers such as DirectShow or GStreamer would only report the decoded frames time, while the MediaFormatReader report the demuxed time.
There is no right answer here. So setting a duration that will allow all readers to pass the tests.
alertsettingscallback only goes to the single observer whereas notifications-open-settings goes through the global observer service.
--HG--
extra : commitid : chMffpyqlT
extra : rebase_source : 35ff4a94fbf14899002a6f2395063bbdc124ff48
This also contains two small fixes to the VBR header parsing logic itself:
- VBRI parsing was previously broken because the offset wasn't calculated correctly.
- Xing-style headers can use a VBR header ID of "Info" as well.
--HG--
extra : rebase_source : 320a5e7b50e16ab3382e7121dd3d41f5fc439b76
DecoderTraits.cpp pulls in MP3Demuxer.h which in turn pulls in mp4_demuxer/ByteReader.h. In that context, for some reason the ByteReader can't find the definition for MediaByteBuffer unless it is prefixed with the proper namespace.
MP3Demuxer.cpp itself compiles fine, but for some reason in Visual Studio IntelliSense complains about TimeUnit and TimeIntervals being undefined unless the using statement uses the full namespace hierarchy.
Also fix a small typo.
--HG--
extra : rebase_source : fc46fc82bf06b61c9ac31c2f4331f84f8557c51e
This patch moves |BluetoothAddress| to BluetoothCommon.h, where it is
available for general use. New utility function convert between strings
and addresses. A new hash-key class allowes for using |BluetoothAddress|
as the key in a hash table.
CanvasRenderingContext2D.cpp has a |namespace mgfx = mozilla::gfx;| synonym.
Since the entire file is within the |mozilla| namespace we can use |gfx::Foo|
anyway, which is shorter than |mgfx::Foo|.
--HG--
extra : rebase_source : abd76713f1741b1b4f078e21d89a0708b7bd65fb
Other modules than MediaTrackLists may want to receive updates on a
DOMMediaStream's track set. This moves the MediaTrackListListener out of
the MediaTrackList class into DOMMediaStream as a general interface.
The logic for adding MediaTracks to the MediaTrackList when
MediaStreamTracks are added or removed from a DOMMediaStream is moved to
HTMLMediaElement as this fits the model better - HTMLMediaElement is the
owner of the MediaTrackLists.
--HG--
extra : commitid : 3I8mAeBB3oL
extra : rebase_source : 66b8ffcfb5343811c181e4169f295b08494f2ee0
This is needed to make tests pass until we have bug 1208316 implemented.
--HG--
extra : commitid : GPSNwBVyD4j
extra : rebase_source : b7cb9cb1678a582fbf85b729b8f43508889f5c78
When play()ing a media element after it has ended, MediaDecoder will
again call MetadataLoaded(). When capturing the media to a
DOMMediaStream, that will attempt to create new MediaStreamTracks in the
stream with the original TrackIDs. That won't work, since the original
tracks with the same TrackIDs have already ended.
We solve it by only explicitly creating MediaStreamTracks in the stream
in captureStream(), and only if they're already known. Otherwise the
tracks will be created asynchronously when available in the underlying
stream.
--HG--
extra : commitid : GPSNwBVyD4j
extra : rebase_source : 3ba4a6fc7cc46a8bedf1799c4c6aa25585361269
TrackUnionStream guarantees that TrackIDs are maintained if no tracks
have claimed them before.
In the gUM case, we have a SourceMediaStream which we wholly own (the
DOMMediaStream's Input stream), piped into a TrackUnionStream which
no-one external is able to add tracks to (the DOMMediaStream's Owned
stream) - addTrack()ed tracks are added to the DOMMediaStream's Playback
stream.
The MediaStreamTracks being enabled/disable refer to a TrackID in the
DOMMediaStream's Owned stream.
Alas, we don't need to forward a track's enabled state, we can just do
it on the source.
--HG--
extra : commitid : GPSNwBVyD4j
extra : rebase_source : 4388211be87ebe8a3839ea031b5c504d642806ab
A DOMMediaStream's owned stream is piped from the input stream which is
under the control of the DOMMediaStream's owner/producer (like
captureStream or gUM). When producers like these create new tracks after
the stream has already been created (the initial set should be available
to JS synchronously), it is nice if the DOMMediaStream picks them up
automatically and create the corresponding MediaStreamTracks.
The OwnedStreamListener added here does just that; creates an owned
MediaStreamTrack when a track appeared in the stream that didn't already
have a MediaStreamTrack.
It also moves the logic for ended tracks from the PlaybackStreamListener
to the OwnedStreamListener as we previously would see a track end in the
playbak stream after removeTrack() and that would be interpreted as the
track ending at the source.
--HG--
extra : commitid : GPSNwBVyD4j
extra : rebase_source : ee7d81282ee3fe0e05b55358dee8fc97a22473fe
Simplifies the structure of MediaManager somewhat. Possible since
MediaManager owns both the SourceMediaStream and the DOMMediaStream.
--HG--
extra : commitid : GPSNwBVyD4j
extra : rebase_source : 494b8b673084ea050420dfaf8d16e44a3bc49672
This lets us separate tracks by ownership like so:
* Input - Owned by the producer of the DOMMediaStream (gUM etc.)
* Owned - Contains Input tracks (per above) or tracks cloned tracks
if this DOMMediaStream is a clone.
* Playback - Contains Owned tracks plus tracks addTrack()ed to this
DOMMediaStream minus tracks removeTrack()ed from this
DOMMediaStream.
--HG--
extra : commitid : GPSNwBVyD4j
extra : rebase_source : fba22e96c6c65a74e012509f3da67a4d7df7a244
Locking to specific tracks lets us dynamically remove and add single
tracks to a ProcessedMediaStream.
--HG--
extra : commitid : GPSNwBVyD4j
extra : rebase_source : 0b1b79077f95bbefc8c71de551c5e3483a7d6ac0
This allows for tracking the input track of an added track (for
ProcessedMediaStream tracks; SourceMediaStream tracks don't have input
tracks) directly in the NotifyQueuedTrackChanges handler, which will be
necessary for locking MediaInputPorts to specific tracks.
--HG--
extra : commitid : GPSNwBVyD4j
extra : rebase_source : 4bed5dffe66b71b7ad23f4c02531d84af25cd316
When workers shut down we discard the event queue rather than running it to completion. Originally workers managed their event queue themselves and would simply iterate through the array of events and cancel them all. After bug 914762 this was done by setting a (thread-)global "canceling" flag and then calling NS_ProcessPendingEvents. But this neglects that a shut down request can be received while the worker is in a sync queue. In this case, calling NS_ProcessPendingEvents will process any events pending in the sync queue, which is *not* the queue we need to cancel.
The fix is, if we are in a sync queue when NotifyInternal is called, to defer clearing the queue until the top-most sync queue is destroyed and we are about to return to the regular event queue. Only then can we call NS_ProcessPendingEvents to clear out the queue. Because we can never process any events from this queue while sync queues are active, the timing of the mass cancellation is unchanged from the perspective of events in the regular queue.
--HG--
extra : rebase_source : f67fbee27c0751068a4e7aaf692cbfc1d3c9aa7c
This patch adds a test that even when we seek from being irrelevant to another
state where we no longer need ticks that we still spin the refresh driver
in order to queue and dispatch an animationstart event.
Currently AnimationTimeline stores animations in a hashmap which means that
when we go to iterate over those animations to tick them we will visit them
in an order that is non-deterministic.
Although many of the observable effects of ticking an animation (e.g. CSS
animation/transition events, mutation observer events) are later sorted so that
the result does not depend on the order in which animations are ticked, this is
not true for in all cases. In particular, the order in which Animation.finished
promises are resolved will vary depending on the order in which animations are
ticked. Likewise, for Animation finish events.
Furthermore, it seems generally desirable to have a deterministic order for
visiting animations in order to aid reproducing bugs.
To achieve this, this patch switches the storage of animations in
AnimationTimeline to use an array instead. However, when adding animations
we need to determine if the animation to add already exists. To this end we
also maintain a hashmap of the animations so we can quickly determine if
the animation to add is a duplicate or not.
Now that DocumentTimeline observes the refresh driver we can use regular
ticks to remove unnecessary animations.
We do this because in a subsequent patch, in order to provide deterministic
enumeration order when ticking animations, we will store animations in an array.
Removing an arbitrary element from an nsTArray is O(n) since we have to search
for the array index first, or O(log n) if we keep the array sorted. If we
destroy a subtree containing n animations, the operation effectively becomes
O(n^2), or, if we keep the array sorted, O(n log n). By destroying during a
tick when we are already iterating over the array, however, we will be able
to do this much more efficiently.
Whether an animation is newly associated with a timeline, or is disassociated
from a timeline, or if it merely has its timing updated, the behavior
implemented in this patch is to simply make sure we are observing the refresh
driver and deal with the animation on the next tick.
It might seem that we could be a lot more clever about this and, for example, if
an animation reports NeedsTicks() == false, not start observing the refresh
driver. There are various edge cases however that need to be taken into account.
For example, if a CSS animation is finished (IsRelevant() == false so that
animation will have been removed from the timeline), and paused
(NeedsTicks() == false), and we seek it back to the point where it is relevant
again, we actually need to observe the refresh driver so that it can dispatch an
animationstart event on the next tick. A test case in a subsequent patch tests
this specific situation.
We could possibly add logic to detect if we need to fire events on the next tick
but the complexity does not seem warranted given that even if we unnecessarily
start observing the refresh driver, we will stop watching it on the next tick.
This patch removes some rather lengthy comments from
AnimationTiming::UpdateTiming. This is, in part, because of the behavior
described above that makes these comments no longer relevant. Other parts are
removed because the Web Animations specification has been updated such that a
timeline becoming inactive now pauses the animation[1] so that the issue
regarding detecting timelines becoming active/inactive no longer applies
since animations attached to an inactive timeline remain "relevant".
[1] https://w3c.github.io/web-animations/#responding-to-a-newly-inactive-timeline
