When dragging a selection handle, it moves to strange position in
scrolled TextView because scroll position isn't took into account.
This issue was introduced by rebase mistaking in
I2a7e87ad08416f4bd01a5f6.
Bug: 28008281
Change-Id: I6217483fcc0b9a7e661f02a1f276114ddd5031a4
This change essentially backs out ag/683646, which added an API to click
on ClickableSpans within a TextView. This API has the flaw, however,
that ClickableSpans are not parcelable, so they are not in general
reported to AccessibilityServices. That means that services will have no
idea what they are activating.
Since the API is not usable end-to-end, I'm backing it out before the
API is final.
Bug: 17726921
Change-Id: I541c6218f2899ff67a6b32a13fd9ae6f3b53b3c4
With Ic025c109539c3b59638, selection action mode is always started
when there is a selection. This makes it impossible to extend
selection using selection mode.
This blocks creating action mode when full screen extracted mode is
started with selection, but it's same as MNC's behavior.
Bug: 27988877
Change-Id: I9614cb16373029189bfc098b6c1d353326e6b518
Sets default gravity value to the aptly-named DEFAULT_CHILD_GRAVITY.
Also cleans up FrameLayout lint warnings, annotations, and whitespace.
Bug: 27576632
Change-Id: I457b13791ff85f2228e61e85e44a502a28439e01
Previously, hasTransientState returned true even when TextView has a
selection that hasn't been created by the user. This unnecessarily
prevents the TextView from being recycled.
This issue was introduced by Ib454b0fbbc2c2f8d198, which fixes that
setHasTransientState(true) is not always coupled with
setHasTransientState(false).
With this CL:
hasTransientState will get true when selection action mode is started.
hasTransientState will get false when selection is removed.
Note that hasTransientState intentionally continues to be true when
selection action mode is terminated with preserving selection.
Bug: 27913323
Change-Id: I960ddfd7221caeb676c23926af06a8a415dec288
In order to fix Bug 18920212, we have to track when a View enters
temporarily detached state and when it exits from that state. To do
that, ListView needs to use View#dispatchStartTemporaryDetach() instead
of directly calling View#onStartTemporaryDetach() because there is no
guarantee that existing applications have internally followed Call-Super
pattern.
With this CL, we are going to expose temporary detach state and its
dispatching methods as public APIs. Major changes are:
1. ListView's indirect children will start receiving temporary
dispatch callbacks. Previously only direct children have received
View#on{Start, Finish}TemporaryDetach() callbacks.
2. TextView can no longer assume that ListView never calls
View#View#dispatchStartTemporaryDetach() but directly call
View#onStartTemporaryDetach() instead. See the commit message
of [1] for details.
This also enables us to do the following fixes, which will be handled in
subsequent CLs.
A. ViewCompat support lib is finally able to rely on temporary
dispatch mechanism without reflection.
B. InputMethodManager is now able to ignore focus-in events from
temporarily detached Views. This will be done in the next CL [2].
[1]: a440b002aa
[2]: Ia79bbd8468f768d546354382b47b39dd31ef7bb5
Bug: 18920212
Bug: 27905921
Change-Id: If8f780f8b71754f7533a65097304113ae1f5cf12
This reverts commit 35e2ea0203.
This patch was based on two different wrong assumptions.
Bug 27822069
Change-Id: I20b1017f91f3fce3c23dd8446459d6f3e3150a48
It turns out that BaseInputConnection has still depended on a private
API named BaseInputConnection#reportFinish(), which was introduced
4 years ago to work around a UI freeze due to an unbalanced batch edit
count [1]. Note that such an unbalanced batch edit count cannot always
be avoidable. It can easily occur in the following situations.
- The current IME crashed during batch edit.
- The user changed the View focus during batch edit.
- The current IME called IMM#switchToNextInputMethod() during batch
edit.
The remaining problem is that #reportFinish() is still an internal API
and only subclasses of BaseInputConnection can implement it, and IMM
calls it when and only when the current InputConnection is
BaseInputConnection or its subclass. InputConnectionWrapper and any
other InputConnection implementations will never receive such a callback
to clean up InputConnection#{begin, end}BatchEdit(), which is considered
to be a major contributor to UI freeze.
To address the above issue, we unhide BaseInputConnection#reportFinish()
as InputConnection#closeConnection() so that application developers can
receive an appropriate callback to clean up internal state including
unfinished batch edit.
[1] I5525d776916f0c42d5e6d4a4282aed590d7f0e9a
9d69ecbf61
Bug: 24688781
Bug: 25332806
Change-Id: I234309c5880c9fe0b299b8bd0f8862796d4dda0d
Allow developers to set different content insets on toolbars and
action bars to be used when navigation buttons or menu actions are
present. Set the default values for these according to the material
spec.
Bug 19317855
Change-Id: I13e04e1f19f0982bf551a3027eb70904d6b4674c
Removes mPopupWidth/Height, which have been moved entirely into the
width and height of the LayoutParams.
Bug: 27878812
Change-Id: Id9fe99c7d57d5c15c7fe10ea95d97be562301a8e
* Fixes a bug in HSV where it was not using unspecified measurement hint
* Fixed a bug in SV where it was ignoring padding and margin when
specifying measurement hint.
* Fixes a bug in both where padding/margin were not taken into account
when re-mausing for fill viewport.
* Fixes a bug in both where the ViewGroup's padding was ignored when
measureChild is called.
Bug: 27602908
Change-Id: I15cb942e0fc2ef39c753ff35d36e1d007f4e05a8
Plumbing through the title of windows so support multiwindow
accessibility.
Adding ability to determine the anchor of a pop-up window so the pop-up
can be traversed as part of its anchor.
Bug: 27687627
Bug: 8449376
Change-Id: I59e98a29fb90029407a26de5bf3d900fed5dd627
Add CSS font-feature-settings URL to get/setFontFeatureSettings method
JavaDoc in both TextView and Paint.
Bug: 27857640
Change-Id: I8c20068801032407d493e4f4a15b89dcf35949d2
This CL fixes a bug in ListView where if items are not selectable,
not focusable(in terms of ListView flags) but get focus (because
they can), ListView would not recover the focus properly although
it would make the child visible.
The major issue seems like AbsListView marks data set changed when
the list resizes. It seems like a workaround for some other issue
and the code is from 2009 so instead of changing it, I've decided
to implement a workaround to minimize the potential of breaking
something else.
Bug: 27488391
Change-Id: I5babd00e97bba7cb8cc9cfd0697ef79dfae12b97
- Only move the popup above the anchor when necessary
- Adjust the y position when displaying the popup above the anchor
rather than changing the popup gravity
- Reduce popup height if it's still too large after repositioning
Bug: 27819843
Change-Id: I1ecc235816a61b9431568a34d3116e286e092c11
Passes the width and height into findDropDownPosition() rather than
relying on global state. Ensures that an update is forced if any
aspects of the LayoutParams are changed during drop down position
computetion. Cleans up method and argument naming.
Bug: 27819843
Change-Id: Id85e2a0e81e0ea6a754dadf7c1d1c2493a5979b0
