We weren't closing the ZipFiles created in WebViewFactory to check
inside APKs - use try-with-resources to get them closed automatically.
Bug: 23072621
Change-Id: I11c6b77e960a7d240d19d22240cac177b6ba27b2
This reverts commit 954d1333c4.
The revert is due to apps calling super.onGeolocationPermissionsShowPrompt see b/22685046
Bug: 22685046
Change-Id: I2a9f42b432a010828a0cafaee064480bb0f91cbe
(cherry picked from commit 0bb7d2e467)
Add a note about WebView reloading the page if the UA string is change
during loading. See crbug.com/315891.
Bug: 22325430
Change-Id: I04f5ab703fd2dcedf0709e4aa1d17b1204df355b
Bug: 21910771
Clarify handling client certificates when using a webview. This is a
documentation change only.
Change-Id: Ida78bd89aa8867c99b4b9e4433e342767e9bac0d
This was not a clean revert!
This reverts commit 2ed6fee15c.
We essentially only revert the functionality for going through a list of
WebView package names and picking the first compatible one.
Except for that functionality we also fetched the name of the shared
library from a flag in WebView and made some minor refactoring in the
initial commit, these changes have been left alone in this revert.
Bug: 21893371
Change-Id: Idb2539dc33cc5f9e2894ecd665c23573c6cba9f3
Deprecate setHorizontalScrollbarOverlay, setVerticalScrollbarOverlay,
overlayHorizontalScrollbar, and overlayVerticalScrollbar. They've been
no-ops for years, ever since WebViewChromium.
BUG:21642246
Change-Id: Ia1062c53fdbaa7a0d282ba79da733a6f3b9ac84f
As part of the API rename from ViewAssistStructure to ViewStructure,
we added a temporary workaround to prevent build breakage. Remove
the temporary workaround since the current unbundled webview package
implements the updated onProvideVirtualStructure API.
Change-Id: I13a5b8dee3e856eb585de53a0750bd52c7a909a7
Changes to the data provided to AssistStructure:
* Text foreground color is correct even if the view has not yet been
painted.
* Text background color is now always 1 (TEXT_COLOR_UNDEFINED) for a
TextView, as it has no separate concept of background color.
* Switch now reports the text size/color/style of the label text
(usually user visible) rather than the on/off text on the button
itself (usually hidden in Material, and not usually revelant when
visible).
Bug: 21080375
Change-Id: I7e15f68d89510a76cab76031c2c8ca6ca3f32435
...from text nodes in WebView
Add a new explicit API for setting the text style information associated
with a view structure.
Also, how about some documentation!
Change-Id: Ia948b2d66382b973d0d00a67172a281ad55ce592
Update WebViewFactory's shared relro handling so that it operates
correctly where libraries are loaded directly from APK files.
Bug: http://b/20810492
Bug: http://b/8076853
Change-Id: I7887c7c0f235388d6a40c366693563b4876de992
Bug: 20557074
There is no need to keep the name PostMessageToMainFrame since
we may choose to not implement the special condition to posting
to a named subframe. And if we want, we can do this by overloading
the function.
Change-Id: I9896ad479e1c30cda500352cfdb1b7d336383568
Currently IMM#mCurRootView is always cleared every time when
IMM#finishInputLocked() is called. We have been doing this since
Iad09cf5dbb7f6f156fd39ed243431432e00f8945 so as not to hold the
strong reference to a DecorView so long time (Bug 6413553).
Strictly speaking, the attached window may continue holding
input focus even after IMM#finishInputLocked() is called.
In this state IMM#focusIn() might have unexpectedly rejected
focus-in event but presumably this might not be obvious, or might
not occur at all because in some situations IMM#finishInputLocked()
has never been called even when the attached view loses input
focus.
In order to fix Issue 20820914, however, we need to call
IMM#finishInputLocked() exactly when the attached view loses
input focus. To make it easier to diagnose any unexpected
regressions, this CL only changes the handling of
IMM#mCurRootView, while the next CL Id6afc8fc64512225578c62557b96
plumbs IMM#focusOut() to IMM#finishInputLocked().
Manually tested following scenarios.
- Repro steps in Bug 6413553. Made sure that IMM#mCurRootView
is cleared after switching back from the current application to
the previous application with back key.
- Test application that calls WebView#showFindDialog(). Made sure
that LatinIME works fine when switching text fields. This is
non-trivial because android.webkit.FindActionModeCallback is
changed in this CL.
- Repro steps in Bug 21144633. Made sure that we can enter
recipient's name in the messaging app.
Bug: 20820914
Change-Id: I219394178e4172bc47864297f1418e677dba25e5
Temporarily make WebResourceError.getDescription() non-abstract
so the current version of WebView doesn't crash on it.
Bug: 20064008, 21063767
Change-Id: I15a1abb5df76263006d14eb589fe0076d5aac582
This reverts commit 97c3813042.
This causes issue with the right IME window getting focus.
Bug: 21144633
Change-Id: I4c75b6e7dd87c10f008444d2059164b52a8f4335
- minor changes in WebResourceError;
- prepare to remove WebResourceResponseBase;
- add immutable mode to WebResourceResponse.
Bug: 21063767
Change-Id: Iaf5f92e3850732c7a888453468e108809b3b782a
It turned out that after the API change from ViewAssistStructure to
ViewStructure, the suggested mechanism did not work, and webview
started throwing abstractmethoderror exceptions. Temporarily
solve the problem by wrapping ViewStructure inside a
ViewAssistStructure. Once Webview APK is updated, drop it.
Change-Id: I09dfe7dac9c2bc7c037d842844c61dd879629470
Despite the fact that IMM#focusOut() are called from many focus
mangement logics, the reality is that IMM#focusOut() has done
nothing more than 6 years. This would not a big problem as long
as IMM#focusIn() is called immediately after IMM#focusOut().
However, situations where only IMM#focusOut() is called,
following fields continue keeping object references.
- IMM#mServedView
- IMM#mNextServedView
- IMM#mServedInputConnection
- IMM#mServedInputConnectionWrapper
Even worse, if the IME is showing software keyboard, it will not
be dismissed.
With this CL, IMM#focusOut() starts cleaning up the active IME
session when the associated view loses focus.
This CL also removes IMM#mCurRootView because it is indeed
necessary for above change. The problem when only introducing
above change can be understood as follows.
1. IMM#mCurRootView is correctly set from ViewRootImpl.
2. IMM#focusIn() is called. InputConnection is established.
3. IMM#focusOut() is called, which triggers
IMM#finishInputLocked() because of above change, which
internally clears IMM#mCurRootView.
4. IMM#focusIn() is called but IMM#mCurRootView is still null.
Because of this the focus-in event is ignored and the
software keyboard does not show up anymore.
In this CL, we simply check view.hasWindowFocus() instead.
As far as I've tested, this change looks to be working well.
Bug: 20820914
Change-Id: Ib4bd70ce0305a6bde6a929bcc6ad20a2b8402a97
A previous CL introduced a new way of encoding view properties for
use by heirarchy viewer. This CL updates all views using the old
@ExportedProperty annotation to use this new method. The older
mechanism will be removed in a subsequent CL.
Change-Id: I6cc23b90cd9da1c6ce89b4caffe54874db203452
Fix the various view assist related APIs.
Also remove the blockAssist view attribute, and instead use
the window's FLAG_SECURE to drive blocking of the entire
hierarchy (which is semantically correct, and will protect
existing apps that have already indicated they need it).
Change-Id: I6beebc86b202809cba0a356cae9607d8d0fb5e78
Add method for loading the shared webview library so that several
packages can make use of it. Also add error codes making it possible
to inspect the reason for failing to load the library.
Change-Id: Ic0833d5d122bae488d380e4e10dd81126bd2358e
In the change in go/ag/672863 we throw an AndroidRuntimeException
instead of a PackageManager.NameNotFoundException when no webview
package exists. This should break devices not using webview since
the NameNotFoundException is used to detect webview not being present
(so that the null webview can be loaded instead). In this patch we
create a new type of exception and look for that one instead when we
want to determine whether the device should or should not have webview
installed.
Change-Id: Ia75dec718d7a5b2c3517671c54be3950badb8bba
Bug: b/19771298
onProvideVirtualAssistStructure API was hardwired to call the super
method prevent any crashes when assist gesture is used. Enable it.
Change-Id: I333f9f024ffb34af6a2cfa7e4b66ae233d73eb41
Use a priority list of WebView packages instead of a single package to
determine which package to load WebView from.
This to allow a future version of Chrome to provide the WebView
implementation.
Change-Id: I42e900f0e63152188ebfcff9e39e0d9a99bc6c90
Use a priority list of WebView packages instead of a single package to
determine which package to load WebView from.
This to allow a future version of Chrome to provide the WebView
implementation.
Change-Id: Id63a31396c8c0afbfd250f43a256ccd5981f7a56
Bug: 19771298
Implement the Webview API to provide assist data. Webview assist
data is provided asynchronously.
Change-Id: I2fbf3e5ce7779ba6664dfbc6a702880fe71d5126
Bug: 19313118
As part of the "better error reporting for Webview" work, a new public
API was defined for MNC release to report blocked loads. However,
we decided to use WebChromeClient.onConsoleMessage for this case.
Removing the API.
Change-Id: I1a599385f1ecdd10ba5a774b0b2a6b9f4bdcbd95
For apps that use WebView but don't override
WebChromeClient.onGeolocationPermissionsShowPrompt the callback should
be invoked with allow set to false by default. This ensures that
the error handler callback in JavaScript is invoked in this case (with
the "User denied Geolocation" error). Currently no callbacks are invoked
at all by default (see http://crbug.com/470500).
Change-Id: I49664906b8cfa6910106c8da1b21b99628adacfc
