The previous fix did not work when the text was ellipsized, because the
test for whether the line was the last line was incorrect. The new test
handles both the end of the buffer and the case where it is the last
line because of ellipsizing.
So this should be the proper fix for bug 14276128 Clipping at bottom of
TextView when lineSpacingMultiplier < 1
This version of the patch also handles the single-line case (which is
computed in BoringLayout rather than StaticLayout).
Change-Id: I88791acc2aa493cc8c599b374f4d213571260b4b
The previous fix did not work when the text was ellipsized, because the
test for whether the line was the last line was incorrect. The new test
handles both the end of the buffer and the case where it is the last
line because of ellipsizing.
So this should be the proper fix for bug 14276128 Clipping at bottom of
TextView when lineSpacingMultiplier < 1
Change-Id: Iac5c96f2273142031c18a27f504f7d6d5fcf823e
Avoid applying "extra" linespacing to the last line of a layout, because
when that is negative, it causes clipping.
Change-Id: I4cc8792fd3444e4118604cc3d0f816d59dfc1e74
This is a fix for bug 7615701 TextView: calling setText with long
strings causes ellipsize to not work correctly. The problem is that the
"break" when the last line was ellipsized did not fully break out of
both loops of the processing logic, but only the inner loop. This
caused the outer loop to restart at the next span, causing the next span
boundary to overwrite the line end of the last visible line.
The fix simply returns from the function in that case, as there is no
further processing needing to be done.
Change-Id: I5b34233ffba6f0f6f1c12b9565b4fc53e83a4892
ExtractedText#partialStartOffset and #partialEndOffset are
from the app, that sets it as it sees fit. We need to
validate them so that we don't crash.
Still emit a warning if this is the case, as this is
not expected.
Bug: 9570771
Change-Id: Id9d6babd1620da39bf0e454b14d7ce716bd9d9d3
An app created a SpannableStringBuilder, one of which's spans was the
instance of the string builder itself (that is, the builder contained a span
that was the builder). This caused infinite recursion in the hashcode()
method because it computes a hash from its fields, including all of its spans.
The fix detects the case where a span equals the current instance and
noops the computation on that span. A similar adjustment was made to equals()
to avoid the same recursion problem.
Issue #11051658 StackOverflowError in android.text.SpannableStringBuilder.hashCode
Change-Id: I742687ab32d81ac51c4b9135f698cf5e96a1d295
Fix for bug 6473708. This patch changes from "last update wins" to
merging together the change regions, in the logic of deciding which
blocks need to be updated for painting, so that when there are multiple
changes batched for a draw, they're all taken into account.
Change-Id: I183d453c436125e5efec7031b4d61b43989653f9
This patch fixes behavior where attempting to place the cursor at
the end of a string where the last character is a combining accent
actually placed it before that accent. This was especially annoying
for editing Thai text, because it made it difficult to delete a
trailing tone mark.
Fixes bug 8947569 "Can't place cursor after combining accent" and bug
10398332 "[Thailand] Thai Language(IME) -- Can't delete Thai tone mark
while writing message"
Change-Id: Ida1933c8f0ab6cdb0200db39891e9389e4bdba86
ActionBar uses a transition to animate text changes. This transition
depends on testing the equality of start/end text values in CharSequence
objects. Without equals(), SpannableString will return false for objects
whose references are different, but whose text is exactly the same.
This CL adds the equals() method, and the accompanying hashcode method,
to ensure that two Spanned implementations will always be equal
if their text and span data are equal.
Issue #10760075 Wrong unread count in actionbar
Change-Id: I5e77d40dd302eca035e8c56d40f3cd0aef8e6424
