1. The clearFocus routine in ViewGroup was clearing the pointer
to the descendant which has focus after calling clear focus
on that child. However, currently clearing the focus of a view
causes the view that loses focus to try to give the focus to
the first focusable which potentially sets the pointer to the
child that has input focus in the ViewGroup but the ViewGruop
essentially clears that pointer. This resulted in having two
focused views at the same time in some cases.
2. AbsListView was not calling the super implementation of add
focusables if the focus type was not accessibility.
bug:6559819
Change-Id: I478dfed000b5de3f9b15e12eb82aa3d34c2301e4
1. Since we added explicit accessibility focusable attribute when
adding focusables views that do so should call this method. Some
views were not updated to do so.
bug:6581924
Change-Id: Id64c0b2d76e5269ebf3fbe17203e73b174bdb843
1. Now the list traversal forward is the exact opposite
of the traversal backward.
2. The focus search starts from the view against which
the call is made as opposed to the one that has focus.
This is now consistent with the rest of the focus search.
bug:6537747
Change-Id: Ida6a696636a3099531155fcbff256f71264f5008
1. Iterators were skipping content on reversing direction.
2. The cursor was positioned at the beginning of the next text segment
when moving forward and at end of the previous text segment when moving
backwards. This is incorrect and now the cursor is positioned at the
end of the segment when moving forward and at the beginning when moving
backward.
3. The cursor position was not properly set when reaching the end/start
of the text.
4. The iterators were reporting strictly the next/previous segment even
if the cursor is within such a segment. Thus, when traversing some
content may be skipped. Now moving forward moves the selection to
the next segment end and the start position is either the old index
if it was within a segment or the start of the segment. Same in
reverse.
bug:6575099
Change-Id: Ib48a649cec53910339baf831a75e26440be6e576
Bug 6476578
The latest bug report show a query.length() of 33 while
mQueryTextView.length() is 0 on line 514.
I can see 2 reasons which can explain this discrepancy:
- the mQueryTextView has a filter, which alters the text.
- some asynchronous event (IME?) changes the text in the mean time.
I would favor the second one, which seems to break a lot of single
thread assumptions in the code and generates other IOOB exceptions.
Note that depending on what they are used for, it may be more consistent
to use mQueryTextView.getText() instead of query in the following
assignment.
Change-Id: Ie8a5486b11a80543f8f90980454933c5a74c073e
are pending
Save the pending position scroll until the data change is actually
serviced before posting it to run. This avoids handler loops on
GONE subtrees or when the view is detached.
Bug 6547649
Change-Id: Iab108cfcb7dd11ece703762d311a5f5985f38c3b
1. ActivityChooserView did not hide the popup window when detached.
bug:6544220
2. ActivityChooserView was calling show popup when it was already
showing it resulting in an incrrect update and losing one item
per rotation.
bug:6522041
Change-Id: Iec1682ca5d27e38caf57214fa86060edf82a2166
Delaying the popup by using removeView instead of removeViewImmediate
caused an error when the removal was actually executed after the parent
window was deleted along with the popup.
Fixes bug 6407801.
Change-Id: Ieb17d58467aaf16e1a24f47187f52766d694ba32
