I still want to assert in the method instead of making it a no-op because I'm
going to work on AudioContext sleep and wakeup soon, and this will catch errors.
--HG--
extra : rebase_source : dd5ea81c6c2c3eb85c89b95995bc436ed840b979
- Added new WebIDL dictionary, ScrollToOptions. This dictionary extends
ScrollOptions by adding "left" and "top", specifying the scroll offset.
This will be later extended with more members to allow scroll offsets to be
specified with logical axes.
- Implemented Window.Scroll, Window.ScrollTo, Window.ScrollBy, Element.Scroll,
Element.ScrollTo, and Element.ScrollBy functions that accept ScrollToOptions
as a single parameter.
- Removed ScrollOptions dictionary parameter from existing Window.Scroll,
Window.ScrollTo, and Window.ScrollBy functions as these have been replaced
with functions accepting a single parameter, ScrollToOptions.
- Added new WebIDL dictionary, ScrollIntoViewOptions. This dictionary
extends ScrollOptions by adding "block", specifying whether the element
start or end will be scrolled into view.
- Replaced Element.ScrollIntoView(bool,ScrollOptions) with
Element.ScrollIntoView(ScrollIntoViewOptions) to match updated
CSSOM-View scroll-behavior specification.
- Added SCROLL_SMOOTH_AUTO flag to nsIPresShell to enable selection of
scroll behavior through CSS.
- Updated Element and Window scrolling DOM methods to enable smooth scrolling
set through the scroll-behavior CSS property.
- Keyboard, scroll bar, mousewheel, and any other events that scroll smoothly
with the general.smoothScroll preference enabled will now scroll instantly
if the scroll frame has "scroll-behavior: instant" applied through CSS.
Had caused a crash in the test_streams_element_capture mochitest on Windows. The issue was that the audio decoder thread was destroying stale media frames by releasing a reference to them. This was causing the release of an Image on that thread, but that thread does not process a MessageLoop so the current MessageLoop is null. This is not a problem. Obviously, any thread that has no MessageLoop can't be the worker thread.
Had caused a crash in the test_streams_element_capture mochitest on Windows. The issue was that the audio decoder thread was destroying stale media frames by releasing a reference to them. This was causing the release of an Image on that thread, but that thread does not process a MessageLoop so the current MessageLoop is null. This is not a problem. Obviously, any thread that has no MessageLoop can't be the worker thread.
When HTMLMediaElement initiates MediaSourceDecoder Shutdown() in cycle
collection, it may no longer have access to the SourceBuffers to notify
through Detach().
The DiscardDecoder() call in TrackBuffer::Shutdown() is too late as this runs
after MediaDecoderStateMachine::FlushDecoding(), which waits for decode tasks
waiting on the MediaSourceResource.
--HG--
extra : rebase_source : 67e276044a251556eda2186d044c7f6b1f4363cd
extra : histedit_source : 4d921a5d2f4c0bce9ed67a3cb769c0d407662d6c
Clearing tracks after Shutdown of TrackBuffers means they are cleared
after any more can be added.
--HG--
extra : rebase_source : afd6c4336f440f59da84465908e25b88619484de
extra : histedit_source : 9e2b5856642e9c2084fc14e6bf79195a67e7bff5
