When the cascading feature is enabled, users can mouseover a
submenu item in a popup menu to expand and open the new submenu
(after a short timeout). Similarly, if a user mouseovers a
different menu item in the original menu, the submenu gets closed
(again, after a short timeout).
This should complete the implementation of cascading submenu
functionality.
Also fix two other issues:
(1) Update some oudated code in PopupMenu that was still opening
the submenu when a user clicks on a submenu item; this
responsibility now lives within the MenuPopupHelper's delegate
MenuPopup class, so it doesn't need to live in PopupMenu anymore.
(2) Fix an issue where icons would be force-set on a submenu when they
should not be. Instead, decide whether to show icons in a submenu
based on whether to show them in the top level menu, as intended.
Bug: 20127825
Change-Id: Ia46852c7f99436065ab4bc234de94dffc0019666
Add a note that the base URL can be sent to servers in
the 'Referer' HTTP header.
Bug: crbug.com/506592
Change-Id: Idf77e898645fe130ad569bd266b61257c4f0e3b3
When removing "all" fingerprints, the request is for ID 0, but
the responses are for the actual IDs being removed. When the
requested ID is 0, don't complain if the response ID doesn't match.
Change-Id: I1c8b5b567ea6164c9e0ce6d436ca3b7a6ba22825
ActivityInfo was missing initialization for the
documentLaunchMode flag in the copy-constructor
and the Parcel constructor. The copy-constructor
is used in multi-user/profile mode to create a
seperate instance of the ActivityInfo per uid
and this was manifesting in the linked bug.
Bug: 21590915
Change-Id: I6f71d94ec32ec6326d23c9b62e9d8d319e2fa25e
This changes application code behavior when the activity relaunches due
to configuration change. It only applies to scenarios, where the
configuration change was triggered by a user generated resize of an
activity (i.e. user drags a corner of an activity and thus changes its
size).
Preserving a window means that we will keep the decor view and non
client decor view around, but remove all children views when the
activity gets destroyed. When the activity gets created again, it will
attach its new content to the preserved view hierarchy. Mind, we
actually recreate application side Window object, since some of its
features might changed, but we retain its elevation (to not trigger
relayout with new layout params).
Preserving the window also means that we don't call the window manager
service to remove and later add the window. Instead, we continue using a
single window state throughout the resize operation.
Change-Id: Ie3d2878ed09c99ff343044bfe7a29a0ba07a265e
Settings in question are:
- accessibility_autoclick_enabled -> Whether the feature is enabled
- accessibility_autoclick_delay -> Amount of time mouse pointer has to
stay still before performing click
Enable/disabled AutoclickController event stream transformation (which
implements the feature) based on the accessibiilty_autoclick_enabled
value
BUG=23113412
Change-Id: I8178d10c09d86713bb4c725c95268a7c5f432eb4
Our system themes were based on configurations that were added post-
init of the system theme.
I96e695441543379e4d5fdf3cc6f18d9e6cf953b4 broke this, because there
was a race condition in the code for rebasing themes
If8fecde76d62738a8e55eddf898eafc468afdba2 (the cherry-picked commit)
fixes the race condition and adds the rebasing back in.
This change cherry picks If8fecde76d62738a8e55eddf898eafc468afdba2.
Bug:23387146
Change-Id: I0725028e48599fc6cd9731ae16c71474dd5827e5
Views are not synchronized with adapter state until a layout pass
occurs, which may cause an OOBE if a list item is removed and an
accessibility node is obtained before the next layout pass.
This CL caches the item's enabled state on the bound view's layout
params, which allows us to avoid relying on the adapter to populate
accessibility nodes. It also aborts actions if the target position
is no longer valid.
Updates the documentation on AdapterView to reflect that the result
of getPositionForView() may not be synchronized with the adapter.
Bug: 23943664
Change-Id: Ic79eaa2e26bec9cd8d90fdab434271bc4f3d8a68
This Cl is just a mechanical removal of redundant casts.
Nothing is changed logically.
Bug: 22285167
Change-Id: I460b781753553c002b6cd232ae5918b7acd616d9
This is just a mechanical merge of nested if statements with a dead code
removal. Nothing is changed logically.
Bug: 22285167
Change-Id: I28c1de84635b68108b25ec32ec58de2128758512
This CL restores the selected position when AdapterView
gets restored, rather than wait until the next measure/layout
pass to do it. After the change, even when the AdapterView
is set to GONE (i.e. no measure/layout pass), the selection
will still be kept up to date.
Bug: 23619366
Change-Id: I09a31b6e2a61ca0edf129af8fe634b83784f9167
- add a startMoving API to initiate a window move from app, once
the move starts WindowManager will take over the event handling.
- detect touch events along window's outside border and start
a resize if necessary
Change-Id: Ic7e8baba34e0aa27a43173e044ffb46e93e219e0
