While it's unlikely to have been a problem as the decoder would have been idled at this stage. During the time the TrackInfo was reset and the decoder actually be shut down, the reference to the object would have been invalid causing a potential UAF.
MozReview-Commit-ID: 7pGJtYRy2Yr
--HG--
extra : rebase_source : d32b8ff393f55685ef182b00f286aea1d1d75464
The issue is particularly problematic with the Apple audio decoder. The Apple decoder relies on the sampling rate to configure the CoreAudio transform.
The actual output rate may be different (such as with HE-AAC). Should the decoder ever need to be reset again, future initialization would have failed as the initial rate was now incorrect.
MozReview-Commit-ID: 7kTiaUYuOgf
--HG--
extra : rebase_source : 00119a13205c610542a2f690ce6c3b9caeb1b69c
Added 2 probes:
1. Breakup by language of initilizations and available voice support for that language.
2. Speak time of narrate.
MozReview-Commit-ID: AGD8nON2m7N
--HG--
extra : rebase_source : 2bbd483bf48b92e290e726cea4f16c6ff5155b58
ff5a4bab0813 (bug 1311791) and 332a08725ed0 (bug 1292071) changed
behavior of the VCS caches. First, the store cache / path was merged
into the checkouts cache. Then the path of the Mercurial shared store
was moved within the cache to always be rooted at the cache root.
Caches are shared across tasks. Tasks can execute on any revision
configured to use a cache. So, when interacting with caches, it is
important to consider how every revision configured to use that
cache will interact with it.
Take this scenario for example.
A worker executes a task where the hg shared store is rooted at
/home/worker/checkouts/src/hg-shared. Then the worker executes a
task where the hg shared store is rooted at
/home/worker/checkouts/hg-store. `hg robustcheckout` will see the
checkout from the first task. But then it sees that the store
it is pointing to is at an unexpected location
(checkouts/src/hg-shared instead of checkouts/hg-store). `hg
robustcheckout` aggressively normalizes state to ensure
consistency. So when it sees this mismatch, it blows away the
checkout and creates one from checkouts/hg-store to replace it.
That's a lot of overhead. And this cycle can repeat itself if
the right combination of revisions run on the worker!
A solution to this problem is to create a clean break from caches
when cache semantics change. In TaskCluster, that means using a
different cache.
This commit introduces a "version" component to the checkouts
cache name. By doing so, we create a clean break from all previous
caches, ensuring all revisions this point forward won't encounter
an hg shared store at an unexpected location. This also paves the
road for easily making additional clean breaks in the future.
MozReview-Commit-ID: JT8yuULKpch
--HG--
extra : rebase_source : 2e5d321e4314ff7543423d3c7837b770b7c8a3a3
The error message refers to video, not audio tracks. Looks like
a cut-and-paste error.
MozReview-Commit-ID: J6ur36FMSRF
--HG--
extra : rebase_source : 626e4b3287ce268d9daee26610a599c721116148
Recognize FLAC as an audio mimetype in MP4Metadata and prefer
the rust demuxer for it. Stagefright does not support this.
MozReview-Commit-ID: 7T4tCSCCNBk
--HG--
extra : rebase_source : b69c6e35d4e48c4d419856ee979eae893dbc72b1
Update to the latest upstream master, including skipping padding
at the end of some boxes, esds parsing and flac support.
MozReview-Commit-ID: GdHEQIrtyLB
--HG--
extra : rebase_source : 97e1d09725d813e0f2b31bed6ce80e16b0701fbe
Can not play mp4 on XP. So add the canPlayType checking for the test failure.
MozReview-Commit-ID: KH70XsQkYYF
--HG--
extra : rebase_source : fc08ea1aad6094757dcc7f72662d0d214b4bdeb7
Use a separate delete command for deleting text, because using regular
composition events for deleting text doesn't seem to work well in
Facebook comment boxes.
Turns out the Facebook comment box doesn't work well if we send
compositions alongside set/remove span events. This patch adds back the
update composition flag, but only sends composition when necessary,
which is only right before we send key events.
Because onImeUpdateComposition is no longer associated with a separate
action, it no longer sends back a reply using AutoIMESynchronize.
Expand RemoveIMEComposition with a flag to allow canceling the
composition. Also, remove the "ideographic space" hack from before
because it's no longer applicable (the test remains so we can catch
any regressions).
When a Gecko text change spans larger than our original request, we have
to do the replacement in parts in order to preserve any spans from the
original request. There was a bug where the selection is moved to the
wrong offset after the three replacements. This patch switches the order
of the two replacements and manually fixes up the selection.
For any text changes that originated on the Gecko side, this patch also
splits the replacement into two parts (delete + insert), so that old
composing spans are properly cleared first. This new behavior changes
the expected result for the test added by bug 1051556, so the test is
changed as well.. I think this new behavior is more correct, but if it
results in regressions, we can reevaluate.
Right now we send a "process-gecko-events" message to
GeckoInputConnection in order to wait on Gecko during testing. However,
now we have GeckoThread.waitOnGecko() to do that, so we can just use
that directly.
Under asynchronous IME, when we check text/selection for correctness, we
have to wait for the IC thread to sync the shadow text first. In order
to do that inside the assert methods, we have to move them to inside
InputConnectionTest, so that they can call processGeckoEvents() and
processInputConnectionEvents().
Also, ignore a single newline character, if present, at the end of the
actual text, because it's a side effect of some editing operations in
Gecko (e.g. clearing all text in an HTML editor).
When switching the IC thread from one thread to another, we can no
longer block on the old IC thread waiting for the Gecko thread. However,
we still block on the new IC thread, waiting for the old IC thread to
finish processing any old events.