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
ContentEventHandler and ContentCache allow 0 length text rect query. However, if selection is collapsed and caret is at the queried offset, they return actual caret rect whose height (in horizontal layout, width in vertical layout) may be different from actual font height of the line.
Therefore, it may cause "dancing" of candidate or suggest window of TIP. Therefore, we should query text rect at least 1 length. Then, even if there is no character at the offset, they computes caret rect with previous character.
MozReview-Commit-ID: 9LprWTPyMsF
--HG--
extra : rebase_source : c0dfad35bcc1961948e21c8b50b21cdf218ba966
When TSFTextStore::GetTextExt() needs to hack the queried range, it means that the method should not return TS_E_NOLAYOUT since the hacks are implemented for that. However, currently, if hacked offset is still at modified offset, it returns TS_E_NOLAYOUT. This causes flicking IME windows.
For avoiding that, this patch adjust the hacked offset to the last unmodified offset or offset of the start of composition string. Even if there is no modified character in the composition string, we can use the offset since even if there is no character at the offset, query content event returns caret rect at the offset and if there are old characters, it returns its rect which the user still see. So, the rect at the composition start is useful until layout is modified actually.
MozReview-Commit-ID: 4zo9mF3m9u9
--HG--
extra : rebase_source : 6dd15b62422b85edf04150f15caaca45d7bc3600
Currently, TSFTextStore::GetTextExt() checks the offset with mContentForTSF.MinOffsetOfLayoutChanged() as "the first offset of modified characters", however, TSFTextStore::Content::IsLayoutChangedAfter() needs actual offset - 1. This is really not useful. So, we should rename it to IsLayoutChangedAt() and check the offset simply.
Additonally, TSFTextStore::GetTextExt() should set previous offset of MinOffsetOfLayoutChanged() when it hacks the queried range for avoiding bug of active TIP since setting offsets to the result of MinOffsetOfLayoutChanged() means the offset's layout is always not computed yet.
MozReview-Commit-ID: 182BMuubtFc
--HG--
extra : rebase_source : 65355fc4e488592f59dfc0b44806571ff0b87cd6
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
