- TextView should request focus before performing selection on
non-editable text, since selection requires focus. On the a11y
service side, input focus should not matter when selecting
non-editable text.
- Remove clickable and long-clickable states, since these are present
due to TextView#setTextIsSelectable.
- Make UI controller changes consistent between SET_SiELECTION and
SET_TEXT. Using SET_SELECTION means the action mode menu won't pop up
and the left/right selection handles won't appear. Interactions
between multiple EditTexts were previously inconsistent
- Delete some obsolete javadoc
Bug: 218357385
Test: builds and install: highlighting is consistent between SET
actions. highlighting works when selecting text in TalkBack, without
the service needing to purposely put input focus,
atest AccessibilityTextTraverssalText
Change-Id: I67986020aa112d45bd670f77b2b415617226c094
1) Update the LineBreakConfig class to be immutable.
2) Do not return null in the PrecomputedText.Params#getLineBreaiConfig API
Bug: 216638444
Test: atest TextViewTest; atest MeasuredTextTest; atest PrecomputedTextTest; atest TextViewPrecomputedTextTest; atest StaticLayoutLineBreakingVariantsTest
Merged-In: I93bcb6ebc35344e34e9bb8a24df375aa7b3a8d81
Merged-In: I07766137ff6639c7d4acaad07dbcf11a2841cdb0
Change-Id: I07766137ff6639c7d4acaad07dbcf11a2841cdb0
Fix: 217730256
Bug: 222537368
Test: Added test in EditTextTest (will merge later when reviewed).
Merged-In: I78354a0f1d955c5b7c1ead044ea49086b3479841
Change-Id: I78354a0f1d955c5b7c1ead044ea49086b3479841
(cherry picked from commit e1f392d171)
While we investigate the root cause of this bug, turn the crash into a
warning.
Bug: 218409359
Test: none; we don't have repro steps for the bug yet
Change-Id: I6d699ea839726adc634a200a0057e316d59ecaa9
(cherry picked from commit 827d967199)
EditorBoundsInfo uses local coordiantes, it was mistakenly set with
screen coordinates
Test: atest InputMethodServiceTest
Bug: 217957587
Change-Id: Iadeaa793d1331b6208e4b19036c45120b0185f64
Re landing with the following changes:
We initially cloned the SurfaceControl handle to avoid locking when
accessing the SurfaceControl from the position listener callbacks
running from RT workers. But this meant the last reference to the
layer handle would only be released by GC. If SurfaceViews are
created and destroyed rapidly, we would be at the mercy of GC to
release buffers.
Original change:
There are three transaction queues that can submit SurfaceView
changes.
1. Buffer updates via BBQ apply token
2. SCC apply token
3. ViewRootImpl BBQ apply token
It makes sense for most SurfaceView changes to be synchronized with
ViewRootImpl draws since the caller can optionally synchronize the
change with main window content.
This change eliminates the tmp transaction that is applied directly
via the SCC apply token and instead applies them with the ViewRootImpl
draw transaction.
Also take the opportunity to scope down mSurfaceControlLock usage.
Test: atest SurfaceViewSyncTest
Test: go/wm-smoke
Test: run mem tests via forrest
Bug: b/217973491, b/221631942
Change-Id: Idba712d146e62d7346920dc4f060cba92d47fada
Bug: 204794759
Rotary scrolling should trigger the stretch edge effect. Mouse
scrolling should NOT trigger the stretch edge effect. This
adds support for rotary scrolling while keeping mouse scrolling
from triggering the edge effect.
Test: new CTS tests. manual testing on emulator
Change-Id: Ibad25bcbc0740f2af2042baf67f7606f15b8c57e
While we investigate the root cause of this bug, turn the crash into a
warning.
Bug: 218409359
Test: none; we don't have repro steps for the bug yet
Change-Id: I6d699ea839726adc634a200a0057e316d59ecaa9
I discovered this error in documentation while I needed to capture "PasteAsPlainText" in an android app.
I suspect it might be missing in other folder too, but I’m not familiar enough with Android to be sure
Change-Id: I77af9b06eb602c4ba60b0744cc02f7449bc4f500
There are three transaction queues that can submit SurfaceView
changes.
1. Buffer updates via BBQ apply token
2. SCC apply token
3. ViewRootImpl BBQ apply token
It makes sense for most SurfaceView changes to be synchronized with
ViewRootImpl draws since the caller can optionally synchronize the
change with main window content.
This change eliminates the tmp transaction that is applied directly
via the SCC apply token and instead applies them with the ViewRootImpl
draw transaction.
Also take the opportunity to scope down mSurfaceControlLock usage.
Test: atest SurfaceViewSyncTest
Test: go/wm-smoke
Bug: 217973491
Change-Id: I0b5741b376e042537c37ec34644e0a048eb4bfe0
1) Update the LineBreakConfig class to be immutable.
2) Do not return null in the PrecomputedText.Params#getLineBreaiConfig API
Bug: 216638444
Test: atest TextViewTest; atest MeasuredTextTest; atest PrecomputedTextTest; atest TextViewPrecomputedTextTest; atest StaticLayoutLineBreakingVariantsTest
Change-Id: I07766137ff6639c7d4acaad07dbcf11a2841cdb0
One of the optimizations ag/12911059 did was calling
SelectionModifierCursorController.show() before
startActionModeInternal(). The rationale was that if we start the action
mode first, SelectionModifierCursorController.show() would end up
invalidating the action mode twice unnecessarily, once for each handle.
However, with this optimization, we are calling
SelectionModifierCursorController.show() even when onCreateActionMode
returns false.
Reverted this particular optimization to fix the issue.
Added a test which was failing without this fix but passing with it.
Fixes: 199380016
Fixes: 214341747
Test: atest TextViewActivityTest
Merged-In: I793f76a23978cbbbbde2d16e8a522615174bcdd5
Change-Id: I793f76a23978cbbbbde2d16e8a522615174bcdd5
(cherry picked from commit 11bd644822)
