AudioStream::DataCallback uses cubeb_get_backend_id to work around a bug in
libcubeb's winmm backend, but calling libcubeb APIs from within libcubeb
callbacks is not safe. Move the query to AudioStream::Init and check a simple
bool from within the callback instead.
So different test timeouts from the same test case will fall under the same bug.
MozReview-Commit-ID: LDstAhOpkYK
--HG--
extra : rebase_source : 9f2b52f237f18f3fecdd076295da4d43e5b30219
This patch does two things,
(1) check v.seekable after calling ms.endOfStream()
As test name suggests, we check seekable after calling endOfStream()
(2) check the time range of v.seekable
The seekable represents the ranges of the media resource [1], so it would be changed after calling ms.endOfStream().
Before calling the endOfStream(), seekable should be [0, ms.duration)
After calling the endOfStream(), seekable should be [0, ms.buffer.end(0))
[1] https://www.w3.org/TR/html51/semantics-embedded-content.html#dom-htmlmediaelement-seekable
MozReview-Commit-ID: 56AIZYVsHhW
--HG--
extra : rebase_source : a1f1df601dc8523cd5d4e58b41cada3c79d494c1
IMEStateManager has a static instance of InputContext which has some nsString
instances. Then, their members will be released after XPCOM shutdown and
that is detected as unexpected destruction.
Therefore, IMEStateManager should release them by itself at XPCOM shutdown.
Using nsTSubstring::SetCapacity(0) is the simplest way to release only the
string buffers.
MozReview-Commit-ID: LMrQxQF9xPn
--HG--
extra : rebase_source : 7cbaf19b76be8db083c10270d0ee436a1c061ea2
This will allow us to verify the entire detection pipeline in real nightly
builds, which will give us confidence that real heap corruption will be
detected and reported properly.
MozReview-Commit-ID: 43Fp2HT8RYy
Use ErrorName() as it provides more useful information for the error detail.
MozReview-Commit-ID: BQUPQGcLd8L
--HG--
extra : rebase_source : 734825c88dfbe79de1e61498dcc24606c50314ee
nsDOMAttributeMap::BlastSubtreeToPieces() uses a hash table iterator
to get an arbitrary element from a hash table. This marks the hash
table as being in use. It then modifies the hash table before the
iterator is destroyed, triggering an assertion. The fix is to restrict
the scope of the iterator so that it is destroyed before the hashtable
is modified.
The existing code is safe because the iterator is never used after the
hash table has been modified.
MozReview-Commit-ID: DUjqewvwEe7
--HG--
extra : rebase_source : 698046af75890c8f52ba15331115b9ff119c689a
Add telemetry to collect the following:
- Number of times a MediaRecorder is started during a session
- Duration of media recordings
- How often we're timing out init of audio and video track encoders
MozReview-Commit-ID: 9Pc2oKNCH1M
--HG--
extra : rebase_source : 16414a5ffa95413458d36295e5508df4c16e6fa9
This verifies that screen content is captured correctly by drawing to a canvas
that is full screen and comparing to pixels in the captured stream.
Note that going fullscreen requires the tab (and window) to be in the foreground
and having focus.
MozReview-Commit-ID: 9SNXaCPm9da
--HG--
extra : rebase_source : bcd1fb1954acacbe4b7c51055f73ffc74a0e978f
It was supporting a simpler case of only drawing in the upper left corner of
the input canvas. This supports that by default still, but also allows the
caller to exactly specify coordinates and size of the rectangle to draw.
MozReview-Commit-ID: GVQh0HqejqU
--HG--
extra : rebase_source : fb48fd1681f0545c53b5cb49b2791f42270ca83c
Our previous strategy was to draw the *entire* video we wanted a pixel from to
a canvas, then extract the pixel we wanted from that. This was all right for
most of our cases where the video was sufficiently small.
However, drawImage is more powerful than that -- we really just need a 1x1
canvas and draw the pixel we want to look at straight in.
MozReview-Commit-ID: ATdFVY3YBUv
--HG--
extra : rebase_source : 47ce69d7d9fd6505d2991895d4484fcc1f746543
I have verified that this fails without the code changes from the previous patch
in this series, and passes with them.
MozReview-Commit-ID: 1respvNVQaC
--HG--
extra : rebase_source : 82007792f23465edb1d286b721edeea850e2aaa3
In some rare cases we can end up with both arguments passed to
nsSMILCSSValueType::SandwichAdd being "empty", that is, having the type
nsSMILCSSValueType but a null pointer.
This can happen, for example, when we have a two by-animations and linear
interpolation causing us to pass the "empty" from-value up as the underlying
value from the first by-animation to the second by-animation (which it will try
to add with its empty from-value).
In this case the result of adding "empty" to "empty" should just be "empty"
which we achieve by just doing an early return (since the fallback behavior for
failed addition is to just use the second argument as the result; note that if
we return true though the result would also be the same).
We don't currently have a test case that produces this for interpolate but it
makes sense that trying to interpolate "empty" to "empty" should likewise fail
and just produce "empty". In this case failing will make us fall back to
discrete animation and just use the "empty" values as-is. Indicating failure,
however, has the additional effect of making us use the special keyTimes
behavior defined for discrete animation.
MozReview-Commit-ID: IZ5qg0Mk5Uy
--HG--
extra : rebase_source : 402e881cd8639885568e0a32fb49aa4dfa7cbbde
On that test-case we have something like:
<body restyle-root>
<element dirty-descendants>
<element-2>
</element>
</body>
If we change the state of element-2 after unbinding the <body>, which clears the
body's flags, but not the children's flags, there'll be no restyle root, even
though our parent has the relevant flags anyway.
This doesn't compromise correctness in any way, so I'd rather drop the assertion
that shuffle a bunch of stuff so it holds.
MozReview-Commit-ID: KFVTkXclKST
--HG--
extra : rebase_source : 089049ba8d5458370eb4175423019a6cd170700c
When sending keyboard events from TabParent to its remote process, TabParent
may give higher priority to them than composition events and selectionset event.
Therefore, the event order between keyboard events and composition events (and
selection set event) may be broken. Keyboard events which should cause
inputting some characters are ignored if keyboard events are fired before
compositionend event accidentally.
This patch gives same priority to composition events and selectionset event
as keyboard event for avoiding breaking the event order.
MozReview-Commit-ID: 53jubwuHVvw
--HG--
extra : rebase_source : ddba2cce5980a354a47ded68e69ef973c00dac4b
Revise the pointer event implementation, includes
- Revise the implementation to fetch preference values.
- Separate the logic to get the pointer capturing frame to PointerEventHandler.
MozReview-Commit-ID: 7pdAr0XFNT2
As required by the recent spec change:
d696468777
MozReview-Commit-ID: Ev6kUk1uLAY
--HG--
extra : rebase_source : 70f8ca3143a8b3bb4e03016b9989925d5a328049
The HTMLAnchorElement macros were basically a verbose version of the
CYCLE_COLLECTION_INHERITED helper macros.
MozReview-Commit-ID: 1bxuKdWUMlG
--HG--
extra : rebase_source : 84f5b0de5b1191d0df5c34bcadf61fca72178769
Removes the XPCOM interface for nsIDOMHTMLAreaElement, replacing it
with binding class usage.
MozReview-Commit-ID: IaX4JFTPZn6
--HG--
extra : rebase_source : 79f9200c6ff9e081a5d9bc21eaa605f88caa99e9
- A user gesture is required only for the VRDisplay.requestPresent
call that initiates the VR presentation, as per the WebVR 1.1 spec.
- The parameters of the VRLayer can now be updated by calling
VRDisplay.requestPresent on an active VR presentation.
- Dynamic resolution switching is now functional:
https://webvr.info/samples/08-dynamic-resolution.html
iMozReview-Commit-ID: BL7aJfF6nqR
MozReview-Commit-ID: CmhbFJ4ij5q
--HG--
extra : rebase_source : 28a3f608b4f821631e81ccdfe7f7824f9508a7b4
nsFrame::SchedulePaint() invokes InvalidateRenderingObservers, and
InvalidateRenderingObservers ends up posting change hints during we are
processing sequential tasks for animations, but we don't allow posting any
change hints while we are in the middle of restyling process.
Though the change hints posted by InvalidateRenderingObservers are not harmful
in this case since the change hints will be processed in a second post
traversal without problems. That's said, InvalidateRenderingObservers stuff
should be processed in display list based invalidation anyway (bug 1284053).
MozReview-Commit-ID: GKVRZ98lvEN