Multiple focusable windows cause undesired behavior around selection
modes. TextView isn't sure how to behave when it loses window focus
with regard to selection handles and action modes need to be focusable
for WebView find on page since it uses an EditText as a custom view.
For now:
* Use a layered window decor for overlay action mode when there is no
action bar requested. This eliminates an extra window and avoids the
issue described for full-screen UIs.
* Disable WebView's find-on-page mode when the action mode's UI will
not be focusable. This only affects WebViews in floating windows.
Also remove the "Text Selection" title for WebView's selection mode at
UX's request, as it is inconsistent with TextView's selection mode and
the string does not fit on phones in portrait even on wide
devices. This now uses the same mechanism used in TextView to decide
whether to use title text.
Change-Id: I80caeecea9b47728cf26bb0a388153ca0bdeafe1
This makes sure that the page's SSL certificate is cleared when the page load
starts.
Follows on from https://android-git.corp.google.com/g/#/c/138147.
Bug: 5287216
Change-Id: I40f74a72dc495c48d7167b7b70a845a8481feb85
Note that this is an incomplete fix, as we do not clear the responses for
connections currently in use, as they maintain their own cache. See
http:/b/5324235.
Bug: 5287216
Change-Id: I18f6638efeff0bee1e7ffed606be1444d683bebd
* changes:
Always update the WebView's SSL certificate, regardless of whether a WebViewClient has been set
Remove superfluous synchronized modifier on SslCertLookupTable.getInstance()
This looks like a copy-paste error from other CallbackProxy methods which call
back to the WebViewClient or WebChromeClient, rather than the WebView.
Also remove '@hide' annotations. These are superfluous as the class is not
public.
Bug: 5287216
Change-Id: If97c4d769cf82563b9c182ba09fc742fbb7e08e9
- Update the description
- Use Throwable rather than RuntimeException
- Log as a warning rather than an error
Bug: 5313494
Change-Id: If13ce2088e7080122db14e5e0565f64e6d6f4320
If restored scale and text wrap scale are set to 0 (meaning the previous
scale wasn't saved), set them to overview and reading level scale
respectively.
Bug: 5230909
Change-Id: If7724e9a0cd948c88d0a001728266a3282083bdc
Bug: 5321358
Destroy does run with this. Ideally we should get rid of the need
to run this on the UI thread at all. GL destroy should instead
take place when the view is detached or something like that.
Cherry picked from master
Change-Id: I693ce83cd607186173d8cf58485c5df28004e52c
nativeSetIsScrolling has other side effects. Just pause picture
updating when WebView loses focus.
Change-Id: I917851c806f35a91a12a25c7457712123669384f
Make sure that the native component of WebView has been initialized
before any native-level optimization involving window focus occurs.
Change-Id: I24ca5fe21657aeb1a1faf5bc36fba5ea11064f86
This prevents animations and other live page content from consuming
too many resources while the user is interacting with a popup window.
Bug 5300522
Change-Id: I40fb6d16d56b540c431172052a1ae7fead7109be
Variable is not needed, and removing unneeded check
Also throwing an exception if sContext gets set to null.
Change-Id: Ic61ba4c88a162eb730e166f0e9f477e809b51f42
Reset the text wrap scale to the correct value (i.e., reading level
scale) on zoom to overview. This addresses the scenario where text is
wrapped at a larger scale following a pinch zoom and double tap to
reflow.
Bug: 5254253
Change-Id: I57f706ef4254dd3f194cc35f109dd48b61b72f73
Use the URL host and path rather than the complete url to store
form autocomplete data. This helps in the situation that a site
uses some dynamic query string on the page that contains the form.
Also set the autoocmplete threshold to 1 so that we don't flick the
autocomplete options up and down as you type the first few characters.
Bug: 5265606
Change-Id: I7b372400062ae34f70a78b786007910dc179b101
