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
If the user cancels the bad SSL certificate dialog, stop loading
and return them to the page they were on previously.
Bug: 3189482
Change-Id: Ie5796a8fdc5ba38e1ab42de5beecf7fa4ecec3ed
Bug:3085564
Do not round the text size when applying it to the WebTextView,
so that it will better line up with the text shown on the web
page.
Modify the WebTextView paint to better match the paint used by
webkit.
Update the padding when the zoom level changes.
Change-Id: I284a6febcba2be21dc1ab3f74c6ab5751e1b19b6
This is mostly for sites which will change content width when first
loaded such as nytimes.com.
Also zoom to reading level if the zoom overview scale has very
little diff from current actual scale.
issue: 3003933
Change-Id: Ie4b32bf6ac109eef145cd59b31f04077226b9052
V8 can be smarter about the memory it uses and the frequency
of garbage collection but we need to inform it of the values
to use. As this varies device to device look it up and store
it on the WebViewCore to be read by native code over JNI.
See also https://android-git.corp.google.com/g/#change,78691
Bug: 3075565
Change-Id: Ib52f4df775b80b386fc98f1d71b5687f01c12b2e
New up and initialise the data structure for tracking autofillable
form fields properly. We should not wait for the first autofill
message from WebCore as we have some special state values we need
to set.
Change-Id: Ic30b9ac69436f784d65e50dcabe6af1ef3326ff4
Native code now provides us with a preview string as well as
an autofill query id. Display the preview string in the
drop down box.
Requires a change in external/webkit:
https://android-git.corp.google.com/g/#change,77132
Change-Id: Ia5e26b98546cda1090142f1720f6a7836be6595c
This is to fix a bug I introduced in one of my last CLs, which is tested
under hw accerlation, and the problem was not there.
issue:3161799
Change-Id: Ic7e7c186d1830c3cbd9359af0e283afbbdfbbac1
If WebCore requests two (or more) alert/prompt/confirm dialogs
in quick succeession, we have a race that when the dialog is dismissed
the WebView does not have it's focus restored before the next dialog
is requested to be shown and we early out of displaying the dialog (i.e.
we do not show it).
Work around this by no longer verifying that the Activity has focus as
this check seems to be redundant anyway (see 3166409).
Bug: 3151825, 3166409
Change-Id: I7f650b066ee63da92bc9a620b8e190c91b306d3e
Bug:2460543
Bug:3094312
Bug:2692655
Bug:2710595
Use the NEXT flag when there is a following
textfield.
In TextView, treat the new variations like email and password
variations.
Requires a change in LatinIME so that these fields work propely:
https://android-git.corp.google.com/g/#change,77721
Change-Id: Id6517a016db7d50b77570ff77f2635027796da4a
Moving some of the code (finding which kind of file it is and
deleting parts of the url) to Java from C++.
Is needed by the following change in external/webkit:
https://android-git.corp.google.com/g/#change,77383
Change-Id: Ifc6008501eb580a0aaa5e307732b6f49ebd19ac4
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.
This change is only for tablet device which has large screen and
good for fixed viewport.
The reflow will only happen in first layout and double tap if the
text wrap scale is not desired.
The initial text wrap scale is set to the reading level, so that if
the web page is in overview mode, after a double tap, the text will
be nicely shown full screen without any reflow.
All the previous reflowing, such as done when zoomed out, are disabled for
tablet device.
issue: 3003933
Change-Id: I8f460704bb27c50d6f5fa259ca2d5007648adfba
These are loaded by the first WebView to be instantiated and read
over JNI by libchromium in external/chromium/android/app/l10n_util.cc
Change-Id: I43d6e5a061691689d28cba2697fedcd27548af08
This option was disabled when doing fixed viewport.
This is fixed with the intention to show at least overview scale,
which will be also fine with phone.
issue:3131279
Change-Id: I2e65d40a90a04f2ca72882fec8096dd8a0d81cb0
The object that carries drawing data between WebViewCore and WebView
uses ambiguous variable names that do not fully convey the meaning
of the values. This change updates those names to make it clear to
the reader what the intention of those values is.
Change-Id: I5a403d44881e1fad366f3ec9930ee59134eccd88
If someone sets mLogEvent to false to prevent logging,
nativeMotionUp will not be called, so touches to WebView
will no longer work. Make sure this does not happen.
Change-Id: Ie79ccc68677cea2f686f7c7da734bf719910f583
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
Matching behaviour that has been in ContentLoader.java since
approximately day 0. Without this, we can't load Gmail attachments
with the Chrome HTTP stack because of permission errors -- we have
to load exactly the URL Gmail tells us.
See http://b/issue?id=3125650
Change-Id: I764036efd428299b2fcd611b62dc046a40d80a55
