Rename StreamBuffer to StreamTracks. We still need a place to keep the track information in every MediaStream, even the StreamBuffer::Track::mSegment is empty.
--HG--
rename : dom/media/StreamBuffer.cpp => StreamTracks.cpp
rename : dom/media/StreamBuffer.h => StreamTracks.h
- The u2futil.js script's verifySignature method was causing an intermittent
in test_frame_register_sign.html due to incomplete ASN.1 decoding. Since
we're calready pulling in an ASN.1 parsing library, this changes that code to
do a complete parse and santizize, which should cover all cases.
MozReview-Commit-ID: 9kDWT2KUFdq
--HG--
extra : transplant_source : %A9CD%CD%E7E%11s%0A%82ls%5B%7B%80jQ%FC%FE%0B
The speex resampler can never return an error in its current state. But just in case and to handle any future changes to the speex resampler.
Also ensure that we can never access a stale speex resampler.
MozReview-Commit-ID: CEME0AA9ghK
--HG--
extra : rebase_source : 3dc40aa0833a85646be6d1d1a3b927fa0b5eb038
Performing all audio processing operations in the same place, allows to simplify the code.
Additionally, if accessibility.monoaudio.enable is not set, we always upmix mono to stereo so that if the first audio stream seen was mono, we aren't stuck playing all future streams in mono.
MozReview-Commit-ID: 5yANN6PLFhX
--HG--
extra : rebase_source : 8b2138368d97f4ec2857c021ed9605c633282ed2
We attempt to avoid unnecessary resampling of 44.1kHz and 48kHz content, for all others we use cubeb's preferred sampling rate as final sampling rate.
MozReview-Commit-ID: 413qnsDFHzY
--HG--
extra : rebase_source : ca3508aefb29e2e64e84774bddb9fe77654c8945
The audio is automatically converted to always match the format of the first processed sample.
This is a temporary approach, as it would be preferred to use a final sampling rate not causing too much quality loss.
MozReview-Commit-ID: Lo3827aon43
--HG--
extra : rebase_source : 946eabde451a33018722cb6f1c0ca7b8c1d87009
This will allow to easily detect audio configuration change prior immediate playback.
MozReview-Commit-ID: IwDUGOd17ND
--HG--
extra : rebase_source : ef2b492cfeed5eca8fdfcb5442dedc2b65fc1d8f
Under some circumstances, the MP3Demuxer is unable to calculate the buffered range which would prevent the readyState value to be recalculated. To get around this we force recalculation when the progress event is fired.
MozReview-Commit-ID: DTaxJjOX4JU
--HG--
extra : rebase_source : 83389805b14c88061e492525abaada1d63b4d5ea
- Move the AppID/FacetID algorithm into its own (potentially reentrant) method
to facilitate Bug 1244959
- Change the Register and Sign operations to be Runnables so that in the future
they can be executed after (future) remote fetches
- Clean up error handling
- Remove unnecessary remote-load Facet test files; we'll re-add some form of
them when the remote load algorithm is completed
MozReview-Commit-ID: 4K1q6ovzhgf
--HG--
extra : transplant_source : /%7F/%96o1%3E%5E%17%20%A2%D0%AA%10%21%88%19%D9%B3%C9
extra : histedit_source : 4d3c61294951920a22e1f1eb7846a2a03f7cd2f0
It wasn't clear which TrackID should be passed to MediaInputPort::BlockTrackId(); source or destination.
MozReview-Commit-ID: I9LoSjdpRwE
--HG--
extra : rebase_source : 20eeb5e4ee47eb1cdf00e94cdc72ee11177bbee2
nsWindow for Windows cannot decide if a preceding WM_*KEYDOWN or WM_*KEYUP which is a preceding message of WM_*CHAR is consumed because nsWindow cannot know if WM_*CHAR message came from same window which received the preceding WM_*KEYDOWN or WM_*KEYUP. Therefore, PluginInstanceChild should do that.
MozReview-Commit-ID: 1uuZ0nTJ5Xb
--HG--
extra : rebase_source : b99f8057d5e93035a769af2506292ff7d2cb8f4a
eKeyDownOnPlugin (mozkeydownonplugin) and eKeyUpOnPlugin (mozkeyuponplugin) should execute if the key combination is reserved by the linked <command> element.
Note that there is no eKeyPressOnPlugin. Therefore, eKeyDownOnPlugin may execute shortcut key handler which is registered as a keypress event handler.
MozReview-Commit-ID: CpjsFW02y26
--HG--
extra : rebase_source : 361be61bc6ff0213e3386427878d2f81321ca0df
If a plugin process posts native key events to the widget, it needs to check if the key combination is reserved by chrome because if it's reserved by chrome, the reserved shortcut key handler should be executed and the event shouldn't be handled by the focused plugin.
This patches add eKeyDownOnPlugin and eKeyUpOnPlugin. nsXBLWindowKeyHandler will listen to them and handle them as normal keydown and keypress or keyup event. Note that these events won't be fired on content in the default event group and won't be sent to the remote process.
MozReview-Commit-ID: H5OKPLtVdr6
--HG--
extra : rebase_source : c6852423e47c40e9953b72061262730f7cce35d7
On Windows, applications cannot handle IME messages asynchronously. Therefore, we cannot put off to send IME messages to plugin even if there are some pending keyboard events which were posted to the parent process.
This patch makes PluginInstanceChild consume all key events which are returned from the parent process during IME composition. And when an IME composition is committed, mark pending key events as outdated.
MozReview-Commit-ID: 7P3LEJ6pDir
--HG--
extra : rebase_source : 42e304c45cd980f339b29526ab65854d196198ad
When PluginInstanceChild receives native key events, it should post the events to the chrome process first for checking if the key combination is reserved. However, posting all key events to the chrome process may make damage to the performance of text input. Therefore, this patch starts to post a key event whose key combination may be a shortcut key. However, for avoiding to shuffle the event order, it posts following key events until all posted key events are handled by the chrome process.
For receiving response from widget, this patch defines nsIKeyEventInPluginCallback. It's specified by nsIWidget::OnWindowedPluginKeyEvent() for ensuring the caller will receive the reply. Basically, the caller of nsIWidget::OnWindowedPluginKeyEvent() should reply to the child process. However, if the widget is a PuppetWidget, it cannot return the result synchronously. Therefore, PuppetWidget::OnWindowedPluginKeyEvent() returns NS_SUCCESS_EVENT_HANDLED_ASYNCHRONOUSLY and stores the callback to mKeyEventInPluginCallbacks. Then, TabParent::HandledWindowedPluginKeyEvent() will call PuppetWidget::HandledWindowedPluginKeyEvent().
MozReview-Commit-ID: G6brOU26NwQ
--HG--
extra : rebase_source : 8140456de278956d2d594e85c7b397ae366b4962
This patch separates Windows' message definition and related definitions from nsWindowDefs.h to mozilla/widget/WinMessages.h because the definitions are useful in plugin module but nsWindowDefs.h cannot be included from plugin module since it depends on some headers in under widget.
MozReview-Commit-ID: KNUAffLMKT1
--HG--
rename : widget/windows/nsWindowDefs.h => widget/windows/WinMessages.h
extra : rebase_source : ae9390e700ca97a0a4eea3b2977d4d5568ce9408
PluginInstanceChild::PluginWindowProcInternal() should use switch-case statement at checking each message because adding new message handler may make damage to the performance and switch-case statement is easier to read for Windows message handler.
MozReview-Commit-ID: KfL0LtHL6GV
--HG--
extra : rebase_source : 3d729cf0c34990019dcf52fad72c748f31ea4d71
When IMEContentObserver stopped observing contents, posting pending notifications to current thread may cause infinite loop because it's impossible to send notifications to widget until the IMEContentObserver is reinitialized.
When IMEContentObserver is reinitialized, pending notifications are automatically flushed. So, in such case, IMEContentObserver::IMEnotificationSender shouldn't clear the pending notifications but don't post the notifications to current thread immediately.
MozReview-Commit-ID: 5xXT3VB4Jjb
--HG--
extra : rebase_source : 5529f1921cffe14b32779199e6919f1252051dcb