| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
By default, WebView allows access to content providers on the system. This
setting allows applications to turn off content urls.
Bug: 1196879
Change-Id: Iad25e7171a57a9ff392cbb39057468d36355b153
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
When using the Chromium HTTP stack, most of the calls to CacheManager
methods are not required, as we're not using its cache. These methods
are now marked with asserts to make this clear.
Also avoid creating the cache database in WebViewDatabase.
This will avoid creating the database databases/webviewCache.db and
the directory cache/webviewCache.
Bug: 3270236
Change-Id: I68f94dde16830ed817454d5e1af961f41b71d018
|
| |
|
|
|
|
|
|
|
|
| |
The new callback allows applications to return a response for a particular url.
Deprecate onLoadResource in favor of the new api. onLoadResource is not
currently being used by the new network stack and applications can post a
message from shouldInterceptRequest to handle onLoadResource.
Bug: 2905943
Change-Id: Icf48ab3110d85d76112b3c3b4a1a8c8a333b82f0
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This method is called from both the Android and Chrome HTTP stacks.
We want the same user-facing behaviour in each case, but the Chrome
code does not have easy access to the same error message strings.
Therefore, I'll have the Chrome HTTP stack provide empty strings
for the descriptions. (See change I9042a2ee in external/webkit).
This CL makes BrowserFrame check for empty or null strings and use
the standard error messages instead.
The strings were package-private, so I did a little cleaning up
to make them public (but still hidden from the API). Using a switch
statement instead of an array because it's more robust and should
be comparably efficient.
Bug: 3172265
Test: Load http://google.com:81 to force a timeout error, check
that the correct message is displayed.
Change-Id: I7dec8dffe8ad9e513fdb90877e0b466e707174a8
|
| |
|
|
|
|
|
|
|
|
|
| |
Each HTTP request sent from a mobile handset is usually required to
include a x-wap-profile header following the UAProf specification. The
value of this header is a URL that points to the location of a
document which specifies relevant capabilities of the phone, e.g.
supported network bearers, video formats or screen size. This change
defines a global string resource that holds this URL, and also adds
the necessary code in the web widget to include this header in HTTP
requests.
|
| |
|
|
|
|
| |
The browser currently does not try to load invalid urls, that can be a problem. Now we only check if the host is correctly encoded.
Change-Id: Ie7380c59d4faab68a2f957e7f1ba8347e15e45a1
|
| |
|
|
|
|
|
| |
This fixes crashes in several XHR layout tests.
Bug: 2218794
Change-Id: Iebe3a2d19f1fa43b8d9c9d7763e818f7195b8ceb
|
| |
|
|
|
|
|
|
|
| |
the new WebViewWorker thread
This fixes the layout test failure in fast/xmlhttprequest/xmlhttprequest-html-response-encoding.html
Bug: 2218794
Change-Id: If86c5dbb72b21400bd0fb6981de1a6fdf9b40fe7
|
| |
|
| |
Fix http://b/issue?id=2480606
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
which should not block either UI or WebKit. It handles
local file access, cache access and trim cache.
Move createCache, saveCache and most of getCache out
of WebCore thread so that slow IO and database will
not affect loading performance. getCache can be still
called from WebCore thread in the uncommon cases
like redirect and POST validation.
Move cache ticker from WebCore thread to WebViewWorkerThread.
Move setCookie from WebCore thread to WebViewWorkerThread.
Remove the unreferenced files in the cache directory
while trim cache.
Confirmed with our SQL expert, Vasu, there is no need
to wrap clearCache with end/startTransaction any more.
http://b/issue?id=2414792
http://b/issue?id=2475242
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Move ContentLoader and FileLoader to this new way
as they involves IO. Will work on CacheLoader later.
Change StreamLoader to contain a Handler instead of
derive from a Handler so that the Handler can be
created in the thread where load() is called.
Rename StreamLoader's old "LoadListener mHandler"
to mLoadListener.
Remove unused import and unreachable exception.
Fix http://b/issue?id=2158613
This improved page_cycler performance in moz/intl by
10-30% as we are not blocked by IO any more.
|
| |
|
|
|
|
|
| |
Refactor StreamLoader and friends since they all use a Context. Change the
successful status to 200 instead of 0. Not sure why it was ever 0.
Bug: 2364322
|
| |
|
| |
http://b/issue?id=2296839
|
| |
|
|
|
|
|
| |
result, we will use (url+postIdentifier) as the key
for the CacheResult.
Fix http://b/issue?id=1980031
|
| |
|
|
|
|
| |
Decode the url before passing down to the local loaders since they do not decode
the url themselves. This was creating a crash on youtube.com since the data url
was percent-encoded and failing to parse from base64.
|
| | |
|
| |
|
|
|
|
|
| |
http://b/issue?id=1022797, we decoded/encoded the url for each request. As
the url can be long, getBytes() and String.init are taking 1.5% in nytimes.com
and 2.4% in cnn.com. By doing a simple URL encoding test, we can shave 1-2
secs thread time during loading.
|
| |
|
|
| |
Also removed an unused variable in RequestQueue.java.
|
| |\
| |
| |
| |
| |
| |
| | |
Merge commit '7a5738624fa78e328b5f36c687c20b9cf0eb5a60'
* commit '7a5738624fa78e328b5f36c687c20b9cf0eb5a60':
Fix #1876303. Even rfc2616 4.2 says that "Field names are case-insensitive.", servers including Google internal uses case-sensitive checking for "Cookie". So change it.
|
| | |
| |
| |
| | |
case-insensitive.", servers including Google internal uses case-sensitive checking for "Cookie". So change it.
|
| |/ |
|
| |
|
|
|
|
|
| |
The semantics of Config.DEBUG will be changing soon, and all other
Config.* fields will become deprecated/hidden.
BUG=1780938
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|