Some languages do break words across lines and words can break between
lines with hyphenation. If a word has only one character on the current
line with the rest of the characters on the next line, the user would
be unable to move the cursor to the end of the word.
Rather than judging if a user is far enough into a word by using the
full word length, this CL amends the logic to only use the characters
that are on the current line of the word, if the user is far enough into
these characters the handle jumps to the next line to the end of the
word position.
Bug: 21400624
Change-Id: I8b96eb83bea08d9794d1e9db74066bcc3e168ac0
Also turns off ViewPager debug, enabled the scroll indicator on the
DatePicker's year list, and updates the year label's TextView ID to
something more reasonable. Some code cleanup inside ListView.
Bug: 20110431
Change-Id: If1dba955094524d69cc297d7a567a182cef7f11d
If you select some text normally while in accessibility mode, it
should be cleared and handles should not show if you initiate text
selection using the accessibility context menu.
Bug: 22071639
Change-Id: I32b966e771ba5715a0ab370e6aa602398e5ec534
Selection start can be bigger than selection end and this kind
of selection is generated by mouse selection at least from L MR1.
To fix and support SHARE button for this kind of selection,
getSelectedText need to invert selection start and selection end
when the selection start is bigger than selection end.
Bug: 22065979
Change-Id: Ide4ac41e3f59d256033aca004450712ca0bb0f03
OnPreDraw is called even if the View is not visible.
So need to check isShown() and hasWindowFocus() before calling
starting selection action mode.
This hack is originally introduced for keeping selection on device rotation.
I manually verified this issue does not revive with this CL.
Bug: 22036870
Change-Id: I814db6165e2345fcacedcbd399c1a3985501c8fd
The text selection handles should be hidden / shown when the window
loses / regains focus.
Additionally renames method to make more sense.
Bug: 22062480
Change-Id: I6e160234cf112ee285367637e2f1c14defd82e89
In TextView's onPreDraw method, startSelectionActionMode()
is called, but the selection has already been started so
in startSelectionActionMode() it shows the
insertionController which hides the selectionController.
Fix this by adding a check to start the action mode only
if it is not already started.
Bug: 22028858
Change-Id: I2999423155b7a63a7d879bc8ea5032e17dff459f
This CL is a follow up to I7998c8ee2162a0e01525a0cd66ec14fa505,
which completely removed ExtractActionMode including back key
handling in InputMethodService when full-screen mode is enabled.
It turns out that back key events still need to be handled in
InputMethodService when full-screen mode is enabled so that
users can still cancel floating text action mode with back key.
Bug: 22034992
Change-Id: I5f8db34f7425eef343d40d9820925ea6aaf9fccc
Do not start the floating toolbar action mode and
do not show the handles if after a rotation when the
extract mode will be started. This fixes an issue where
onTouch after rotate duplicates the handles in extracted
mode.
Note: if NO_EXTRACT_UI flag is set then the toolbar,
selection and handles preserve their state.
Bug: 21960251
Change-Id: I1c7881bf2f40d8877fa0ce26e27a29398edc1296
WordIterator's getEnd/getBeginning methods does not support the needs
for word boundary detection in text selection. Consider the words
AABB (where AA and BB are each words). If getEnd is given the offset
on the boundary between AA and BB, it would return that offset since
it is the end of AA. For text selection we always want the "next end"
if available.
This CL adds two methods to word iterator that return the next end
and previous beginning.
This CL also alters the code in Start/EndHandle to use the x value
and current / prev line positions to determine if the user is
expanding or contracting the selection.
Bug: 21305292
Change-Id: I6e7a83e53e245d71e43d78f1957f844f2ed1cdfb
Select with double tap in extracted mode has suffered
a regression recently: flickers and it does not correctly
select. Found this fix after a lot of trials.
Bug: 20128047
Change-Id: I1bbe8c11982d37e5409bac2b648a31b0ca1f0bbc
The issue states that NumberPicker.setWrapSelectorWheel(false) only works
in a specific call order. The underlying problem is that NumberPicker
does not remember user's preference on whether the selector wheel should
be wrapped. Therefore, it only works when user sets their preference last,
after everything else that could affect the choice gets executed.
Bug: 19049714
Change-Id: Ic27d909cb3dd657993a4df9a04c819b6965ad11b
