Be more conservative with when we let an AutoCompleteTextView's
dropdown box of completion suggestions cover the IME.
Disable the expand-when-touched behavior of the dropdown list when
more than 3 items can be seen at a time without it.
Don't let a ListPopupWindow that is expanding in response to touch
scroll the anchor view within its parent and slide the dropdown out
from under the user's finger.
Change-Id: I009accfd4e841c9a5e1072735d8a0b067a0bc06a
SF kept a strong reference to ISurface until the
window manager removed the surface from the screen.
This fell appart when running standalone tests, that is
when the window manager wasn't involved.
When the window manager is around, it would clean-up surfaces
even when an application died.
with this change, SF is able to do its own cleanup without
relying on the window manager.
the change is very simple, we simply don't keep a reference
to ISurface and make sure no more than one of them can
be created.
Change-Id: I61f2d7473bf8d4aa651549a846c34cdbb0d0c85a
The JavaDoc says that if the "...count is negative then the
characters before index are measured in reverse order. This
allows for measuring the end of string."
However, the native code doesn't work its way backwards
from the given index when the count is negative. It always
passes Skia the substring starting from index and the
absolute value of count.
Its better to fix the JavaDoc rather than the behavior, since
this API is public and has been this way for some time. It
is also used by TextUtils.ellipsize indirectly, so its best
to avoid breaking that sensitive code.
Change-Id: I8bd51def6ec98251e355370710eb44f58fb737c4
Bug: 3460867
This change has BrowserFrame intercept browser:incognito URLs to
provide a localized version of them. It also adds a spanish
translation for the page.
Change-Id: I888453d895ea1047544a09ba7f23645e2746bea6
[This is the WebView part]
The idea is to turn on the visual indicator without building the code.
The implementation included:
1. Setup the UI on browser side to check whether or not this is enabled.
2. Transfer the info from browser setting to web setting.
3. Send this info down from WebView to webkit.
4. In the webkit, we save this info in TilesManager.
5. At texture generation time, we query this info to decide whether or
not add the visual indicator on the texture.
One design decision we made is we don't want to restart the browser for
debugging purpose. This is better preserving the browser current activity,
the only pitfall is that the visual indicator is NOT updated on different
textures simultaneously.
The corresponding browser change is: #change,97058
The dependent webkit change is: #change,97052
bug:3458721
Change-Id: I34a0514048df61b414c3386b292f2586efbde74e
Even if it's just to tell them that we don't support any (this is optional).
Change-Id: Iee50b4020f28a47dfbe5d56f1732fe044b3b3655
related-to-bug: 3353752
Even if it's just to tell them that we don't support any (this is optional).
Change-Id: I557865ac00d0fb65ffa69363eb1eceaabe522a1a
related-to-bug: 3353752
HAVE_ANDROID_OS was defined as "1" for targets, but never defined as "0"
for non-targets. Changing them to #ifdef should be safe and matches
all the other uses of HAVE_ANDROID_OS throughout the system.
Change-Id: I82257325a8ae5e4e4371ddfc4dbf51cea8ea0abb
