Rather than asserting that the bit depth is 16 bits, let it fallback to other PDMs
MozReview-Commit-ID: DnO3nvgEFAe
--HG--
extra : rebase_source : 486e2aece7ebbbdf7058a6580198b1dc5c97247a
The only non-trivial implementation of this method is in nsEventTargetSH, but
it's never called, so no point keeping it around. (Similar methods were removed
in bug 1132184 and bug 1132187.)
It's never defined, and there's a comment in
XPCWrappedNativeProto::CallPostCreatePrototype() explaining how
PostCreatePrototype() doesn't have an associated "want" check.
Changing the setting currently won't take effect until you rotate the tabs
panel (to cause it to be recreated); that will be fixed in the next commit.
MozReview-Commit-ID: HZfQRy8zubV
--HG--
extra : rebase_source : 78c3606eb55146afe3d59b0cdfa623999f09796b
P2 fixes the test because it forces HAVE_ENOUGH_DATA when endOfStream() is called.
MozReview-Commit-ID: CK5CHvoS9bU
--HG--
extra : rebase_source : 96ff8f773234ad1b2bbc685381c94f6df30d4dea
extra : source : 7f9fb0cbe6e0e8aa5d727417357dfa976f297014
It is safe to call Tell() on the main thread because it won't block the main thread like Read() does.
MozReview-Commit-ID: 64B41l8fe1
--HG--
extra : rebase_source : b5fc0ec44e8c238841c4f4329d14a0e476f7e422
extra : source : 3d229e2cc659d262ce04c4b09b3484b6524af4b4
http://searchfox.org/mozilla-central/rev/dc8cf05768b83a6ef0b4039edd6efddd56ee4109/dom/media/MediaDecoderStateMachine.cpp#1065
Changing nextFrameStatus to UNAVAILABLE might change readyState to HAVE_CURRENT_DATA and cause 'waiting' to fire.
It doesn't make sense to fire 'waiting' at the end of playback.
http://searchfox.org/mozilla-central/rev/dc8cf05768b83a6ef0b4039edd6efddd56ee4109/dom/html/HTMLMediaElement.cpp#5423
Note the check for Ended() doesn't work as expected to prevent 'waiting' from firing at the end of playback
because of the way how TailDispatcher schedules stateChange tasks.
This patch keeps readyState in HAVE_ENOUGH_DATA when playback is near the end for wanting no more data.
readyState will change to HAVE_CURRENT_DATA when the playing state of MediaDecoder is changed to PLAY_STATE_ENDED.
MozReview-Commit-ID: 6EspaD2hhx
--HG--
extra : rebase_source : 345aad2757d684e24863ae2daf506b035955efe7
extra : source : 56736efbab04a5c2d66faf2514bac93acf4c79f7
Convert JavascriptBridge, JavascriptTest, and other relevant code to use
the new Bundle events. We used the same "Robocop:JS" event for
communicating both ways before, but now that we have a unified bus, we
need two different events, "Robocop:JS" and "Robocop:Java" for two-way
communication.
Convert events that are only used in robocop tests to Bundle events,
which are then used through Actions.expectGlobalEvent /
expectWindowEvent.
"Content:" prefix is added to "DOMContentLoaded" to follow the event
naming convention.
SelectionHandlerTest.java is removed because it's no longer used
anywhere.
When converting a JS object to a GeckoBundle, convert the property name
to a string if necessary, because the property name could be another
type such as an integer.
I noticed that our current behavior in ContentRangeInserted is incorrect. Unlike
ContentInserted (where this code lived originally), ContentRangeInserted takes a
start and end element. I'm not sure if we ever take that path for new content that
needs style, but it seemed sketchy. And generally, it seems nice to just always
style new content the same way (though we still need to style NAC by the subtree
root, since it hasn't been attached to the parent yet).
For situations where there is indeed only one unstyled child, the traversal
overhead should be neglible, since we special-case the single-element in
parallel.rs to avoid calling into rayon.
Being more explicit about what we want here also makes us more robust against
the other handful of callpaths that can take us into
nsCSSFrameConstructor::{ContentRangeInserted,ContentAppended}. Currently we
can call StyleNewSubtree on an already-styled element via RecreateFramesForContent,
which triggers an assertion in the servo traversal.
MozReview-Commit-ID: DqCGh90deHH