Bug 1154802 provided a workaround for this race condition. So enable it in all platform.
MozReview-Commit-ID: BS1iW4O7TsZ
--HG--
extra : rebase_source : ac825a25b195b22106ae70cb412a0b61bd846bfb
JS can create empty text nodes. Therefore, ContentEventHandler::GetLastFrameInRangeForTextRect() shouldn't use it for computing retrieving a text frame (Although, such text nodes shouldn't have primary frames).
MozReview-Commit-ID: EJAthEpNZNU
--HG--
extra : rebase_source : ccd05b46911077daa855a5c085839fd14aadc2ee
nextNodeOfRangeEnd is used for excluding unnecessary node for computing text rect. When aRange ends at start of a text node, the frames which are created for the text node shouldn't be used. However, if the end node of aRange is same as the start node of aRange, the node is not outside of aRange.
This could occur when it's called with empty range or there are some empty text nodes.
MozReview-Commit-ID: C1yCN5WrULe
--HG--
extra : rebase_source : 35d5b8feecd351bef29fe4af79a0f6f5bdad8bec
The previous patch in this series renamed nsCSSProperty to nsCSSPropertyID.
This patch renames nsCSSPropertySet to nsCSSPropertyIDSet accordingly.
This patch is generated by the following commands (note: if you're running
using OS X's sed, which accepts slightly different flags, you'll have to
specify an actual backup suffix in -i, or use gsed from Homebrew):
hg stat -c \
| cut -c 3- \
| tr '\n' '\0' \
| xargs -0 -P 8 gsed --follow-symlinks 's/\bnsCSSPropertySet\b/nsCSSPropertyIDSet/g' -i''
Then:
hg mv layout/style/nsCSSPropertySet.h layout/style/nsCSSPropertyIDSet.h
... and finally, manually renaming nsCSSPropertySet in the include guard in
nsCSSPropertyIDSet.h.
(NOTE: Re-landing this patch on a CLOSED TREE to correctly-address the merge bustage that closed the tree.)
MozReview-Commit-ID: ASUNs7FWbKP
--HG--
rename : layout/style/nsCSSPropertySet.h => layout/style/nsCSSPropertyIDSet.h
This patch is generated by the following commands (note: if you're running
using OS X's sed, which accepts slightly different flags, you'll have to
specify an actual backup suffix in -i, or use gsed from Homebrew):
hg stat -c \
| cut -c 3- \
| tr '\n' '\0' \
| xargs -0 -P 8 gsed --follow-symlinks 's/\bnsCSSProperty\b/nsCSSPropertyID/g' -i''
Then:
hg mv layout/style/nsCSSProperty.h layout/style/nsCSSPropertyID.h
... and finally, manually renaming nsCSSProperty in the include guard in
nsCSSProperty.h.
MozReview-Commit-ID: ZV6jyvmLfA
--HG--
rename : layout/style/nsCSSProperty.h => layout/style/nsCSSPropertyID.h
The merge from inbound to central conflicted with the merge from
autoland to central, it appears. Per tree rules, the commit from the
autoland repo wins and the inbound commit gets backed out.
CLOSED TREE
--HG--
extra : amend_source : 927e1cdfa8e55ccbd873d404d905caf6871c8c4f
extra : histedit_source : 07095868c3f767258e1d7d2645193bf4811b13bb%2Ca49ae5a28bf6e67298b6208ee9254c25a2539712
We can get out of A/V sync if the decode is struggling to keep up. This is
because of the loop in VideoSink::UpdateRenderedVideoFrames(). If this function
runs while there's only one frame in the video queue, we won't drop that one
frame if it's late. If we're struggling to keep up, it's increasingly likely
that we'll end up running this function with only one frame in the video queue.
That results in us entering VideoSink::RenderVideoFrames() with only 1 late
frame, which the compositor dutifully draws. Resulting in a late frame being
drawn, and thus broken A/V sync.
This change makes VideoSink::UpdateRenderedVideoFrames() drop all late
frames, even the last one in the video queue. We now keep A/V sync when the
decode is struggling to keep up. However, if I do this, we end up dropping
(and reporting that we drop) a lot more frames, and thus rendering a lot fewer.
But since we when we drop the frames we report them as dropped, a well written
MSE player can detect that we've failing miserably to keep up, and and lower
their bitrate.
MozReview-Commit-ID: ybkq48mKk2
--HG--
extra : rebase_source : f03c186059a365a45de698b2a30e632daae47fb8
We've proven that when seek is in action, mQueuedSeek.Exists() is always false and mCurrentSeek.Exists() is always true.
MozReview-Commit-ID: CxNU45NXG88
--HG--
extra : rebase_source : 893dbe33cb2f66b9a0bc7ddb03afb40f06d574d0
InitiateSeek() is called from several places where we can prove mQueuedSeek.Exists() is false:
1. MaybeFinishDecodeFirstFrame(): mQueuedSeek is moved when calling InitiateSeek().
2. Seek() rejects mQueuedSeek before calling InitiateSeek().
3. StartDecoding(): mQueuedSeek is moved when calling InitiateSeek().
4. VisibilityChanged(): it doesn't call InitiateSeek() when mQueuedSeek.Exists() is true.
MozReview-Commit-ID: BriPw0VID5O
--HG--
extra : rebase_source : 1417b108eab1cf9cf332e55e77077d7947505d27
In some cases, we need to resend missed VideoSegment to new added MediaStreamVideoSink. Append the latest video frames from updateTracks.
MozReview-Commit-ID: 76RFs5fgKpY
--HG--
extra : rebase_source : 1b1e4e60e0653cbf4ef21abf364239514cf171c5
