Same as selection change notification, text change notification shouldn't be notified to TSF while there is cachec content because neither TSF nor TIP may allow to change text by web applications during keeping storing cached content.
This patch makes TSFTextStore stores and merges text changes until MaybeFlushPendingNotifications() is called and there is no cached content.
MozReview-Commit-ID: 9fj0GREbX18
--HG--
extra : rebase_source : 71db6b4b9f0ab979313398a8014bde992183e019
TSFTextStore shouldn't notify TSF of selection change until MaybeFlushPendingNotifications() is called and there is no cached content because while there is cached content, neither TSF nor TIP may allow to change selection by web applications. Therefore, ITextStoreACP::GetSelection() and similar methods need to use mSelection instead of actual selection in the focused editor. Therefore, TSFTextStore should store selection change data during keeping storing content cache and notify it when the cache is cleared. So, when TSFTextStore notifies TSF of selection change, TSFTextStore needs to update mSelection to the actual selection which is stored in mPendingSelectionChangeData.
MozReview-Commit-ID: 8ZWASzu7Znv
--HG--
extra : rebase_source : 0bfaef0bbffd72d661c84992cc8c842215e3407a
EnsureAudioDecodeTaskQueued() is called from several places where
mReader->IsWaitingAudioData() can be proven to be false:
1. OnAudioDecoded() - definitely false.
2. OnNotDecoded() - false because aReason is MediaDecoderReader::CANCELED.
3. OnSeekResolved() - false becuase we haven't requested any samples.
4. SetCallbacks() - false because AudioWaitCallback is resolved.
MozReview-Commit-ID: 8ppYIQQw0uK
--HG--
extra : rebase_source : 721ab44f6c23b87edfbe6d132fca9d85ca468368
This patch stop clearing mContentForTSF at unlocking the document because we should keep it until active composition is committed. If so, TSF/TIP won't be confused by content changes by JS. So, this is important for a11y of TIP users in some complicated websites like GoogleDocs, Facebook, etc.
Note that this patch doesn't work well without following patches. We need to stop notifying TSF of selection changes and text changed while mContentForTSF is valid.
MozReview-Commit-ID: 9QOGZxdYU3I
--HG--
extra : rebase_source : 19a6eeb2357825643497caf5a5298c55f08a0670
We need to request another audio sample in OnAudioDecoded() only when
mDoneAudioSeeking is false which also applies OnVideoDecodd().
Therefore we remove calls to Ensure{Audio,Video}DecodeTaskQueued()
from CheckIfSeekComplete() to prevent requesting video samples inside
OnAudioDecoded() for they will be handled by OnVideoDecodd().
This also allows us to remove checking of mReader->IsRequesting{Audio,Video}Data()
from Ensure{Audio,Video}DecodeTaskQueued().
MozReview-Commit-ID: LpXjiacp0D9
--HG--
extra : rebase_source : 14d2b2de81ec386a50e26fd75ac2b1087d2950b5
Running the test-case in the bug, and profiling under OSX using Instruments'
time profiler, the time spent in `AudioEventTimeline::ValidateEvent` was the
highest Web Audio API-related function. This patch makes it disappear from the
profile. We already use the same technique on the MSG thread to keep the number
of events low.
MozReview-Commit-ID: GJLPRWBh7nQ
