| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ART uses the class object's embedded monitor to protect class
initialization - the same monitor used by "synchronized" applied to
static methods. This can cause deadlock in extremely rare cases of
preemption during WebView code loading.
Remove synchronized from all static methods in WebView, to avoid this
deadlock. In most cases the synchronized is simply unnecessary in the
Chromium-based WebView implementation; in CookieSyncManager we instead
use a separately allocated Lock object to preserve thread safety.
Bug: 27417671
Change-Id: I13049f23fc984b77a3f4c203a5c698858c64abfe
|
| |
|
|
| |
Change-Id: I031443de83f93eb57a98863001826671b18f3b17
|
| |
|
|
|
|
|
|
| |
Putting the deprecated at the beginning of a class comment seems
to cause problems with JavaDoc so I've moved it to the end.
Bug: 16799480
Change-Id: Ia23dab2ad8ceb8e107e047480b5cb324d11a1457
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Documents the defualt settings of acceptCookies and acceptFileSchemeCookies.
The current defaults:
<L >=L
acceptCookies | y | y |
acceptThirdPartyCookies | y | n |
acceptFileCookies | n | n |
Bug: 11575158
Change-Id: Ia6cb71bf80608cb2ea8049192f33616e57c15801
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The CookieSyncManager is largely useless as the WebView
automatically syncs cookies every 30s (whether you like it
or not). The one method which needs to be saved is sync,
there is no other way to force a sync without this.
We move sync to the CookieManager and rename it to flush
for greater consistency.
Bug: 11060034
Change-Id: I8a14998020eea54f196fc6ed845b09ed69cfd447
|
| |
|
|
|
|
|
|
|
| |
Delete all the Java classes used only by the old WebView implementation,
and also sections of common classes that were only needed for the old
WebView.
Bug: 10427705
Change-Id: I02549a71104b35d86d99058c71f43e054730ec7d
|
| |
|
|
|
|
|
|
|
| |
Add a workaround to ensure that the WebViewDatabase and JniUtil can
still be initialized as side effect of making a CookieSyncManager
This was collateral damage from the fixes for Bug 10932261
Change-Id: If5ba65a7822d5b0afc14139dd84125058bf96897
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug 10932261
Most of this flow exists purely to get the Context from
CookieSyncManager.createInstance over to WebViewDatabaseClassic. Make
that depenency more explicit (with a TODO to remove it) and this allows
a much simpler CookieSyncManager implementation for the normal case.
Note after this patch, CookieSyncManager.getInstance() is technically fine
to call without a prior call to createInstance, but retaining the
ordering requirement as a convenience for anyone developing on new OS
but still supporting the older versions.
(Note that CookieSyncManager instance is not required for correct
operation of either existing webview, so these changes only impact
the public API contract of object lifetimes, not the underlying
implementation)
Change-Id: I51fdd6622704f1c749277fee6df2f84ac4c704d2
|
| |
|
|
|
|
|
|
| |
Last remaining bits:
- push JNUUtil.setContext call down into WebViewDatabaseClassic
- remove references to hidden ClientCertRequestHandler from the public API classes.
Change-Id: I9605dc2493b73fe8f22c7bb38c73d36632e0c7fa
|
| |
|
|
|
|
|
| |
See b/5495616.
Bug: 6228353
Change-Id: I16cfd7b37973919d5bf14d2d80954caede264961
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
All future releases will use the Chromium HTTP stack and maintaining two HTTP
stacks adds maintenance overhead. The Chromium HTTP stack requires V8, but we
now use V8 in all build targets (b/5495373), so we can safely drop the Android
HTTP stack.
LoadListener, HttpAuthHandlerImpl, Network, SslErrorHandlerImpl, WebViewWorker
- Android-stack specific, removed
StreamLoader, FrameLoader
- Require LoadListener, removed
CacheLoader, ContentLoader, DataLoader, FileLoader
- Extend StreamLoader, removed
BrowserFrame
- Removed methods that create LoadListener
- BrowserFrame.startLoadingResource() is called from native
CallbackProxy, WebView
- Removed calls to Network methods
CacheManager, CookieManager, CookieSyncManager, WebViewCore, WebResourceResponse
- Removed other Android-stack specific code
JniUtlil
- Removed useChromiumHttpStack()
WebViewDatabase
- Removed all code to create cookies and cache databases for Android HTTP stack
See corresponding WebKit change https://android-git.corp.google.com/g/166327.
Bug: 5495616
Change-Id: If491675516f6eb187077af4220214bb6e6a8d045
|
| |
|
|
|
|
|
|
| |
Variable is not needed, and removing unneeded check
Also throwing an exception if sContext gets set to null.
Change-Id: Ic61ba4c88a162eb730e166f0e9f477e809b51f42
|
| |
|
|
|
|
|
| |
Not calling redundant android stack cookie code when the chrome
stack is enabled.
Change-Id: I6faea89295e0cae02f5aa19a6ddeec43a4b73a44
|
| |
|
|
|
|
|
| |
I previously tried to make this a new public API, but I realised
it should actually hang off the existing code in CookieSyncManager.
Change-Id: Ic44334008266bad5ba1245cf674350a4c10712ce
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The reason for this is that the CookieSyncManager might not be
initialized right after a webview is created since the initialization
is done with a message.
If someone creates a webview and tries to access a cookie right
afterwards that would cause an unintended exception.
This requires a change in external/webkit
Bug 3172863
Change-Id: I4f4f162253e2af09f63ee582bfce9f75ccf4037b
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
CookieSyncManager
Currently these paths are obtained from the BrowserFrame via JNI.
However, the paths are not synced to the BrowserFrame until the
WebCore thread has started up. This means that if the
WebRequestContext is created on the IO thread, the paths may not be
available.
This change moves the paths from BrowserFrame to CookieSyncManager to
avoid the need to wait for the WebCore thread.
Note that the new methods may be called on either the UI or WebCore
threads, so are synchronised.
Requires a change to external/webkit ...
https://android-git.corp.google.com/g/76579
Change-Id: I8e910ee209c570e90181bd308a78d1987b4d120c
|
| |
|
|
|
|
|
|
| |
Fixes #2296601.
WebView and its related APIs are keeping static objects that hold references to
Context instance. This could cause applications to leak their first Activity
and all the associated resources.
|
| | |
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| | |
The semantics of Config.DEBUG will be changing soon, and all other
Config.* fields will become deprecated/hidden.
BUG=1780938
|
| | | |
|
| | | |
|
| |/
|
|
| |
Double-tree rendering is deprecated.
|
| |
|