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
Must be submitted with corresponding C++ change (I50da7599).
When opening a text file in the browser, WebKit was attempting to
display it as a movie. This is because the media player now reports
that it can handle various document formats, including plain text.
See http://b/issue?id=3132917
This CL updates WebViewCore.supportsMimeType() to explicitly check
for audio and video formats only. This is called from WebKit via
JNI, and doesn't seem to be used elsewhere, so it should be a safe
change to make. Renamed to isSupportedMediaMimeType() for clarity.
Test: push a text file to /sdcard/foo.txt, and open it in the
browser (as file:///sdcard/foo.txt).
Change-Id: Id39b770b05ced7c976d8043649845f26115b24c9
This is to solve macworld.com, which has 900 as viewport but actual
content width is more 1000.
issue: 3003933
Change-Id: I2db3f66828fd00c8be62131599395eb82752b4a2
This is to eliminate false scrollEvent to webkit. And the side effect
is that the history scroll position will be correctly restored;
otherwise, webkit think there's user scrolled and not send back history
scroll position.
Particulary for NEW_PICTURE_MSG from webkit, the scroll event because of
it are not user-scrolled.
issue: 3063945
Change-Id: I9fdbfcb8baf07baf2331e2c4eed66f88aea744ef
This will be required when hooking up CookieManager to the Chromium
stack, as we need to decide in Java whether or not to call into native
code.
Bug: 3116410
Change-Id: Ibe2f7687655a93993b19f4fb9b4fed137b3b9466
After the recent Chromium merge to 7.0.540.0, it seems that we are no
longer allowed to use a profile unique id of 0. Set the unique id
in the AutoFillProfile class so that WebKit can access it.
Change-Id: I88cd1e91b8c6043c732a1709a89fda4a3c9f921f
