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
You can now call goAsync() and move your work to a background thread.
If you are that kind of receiver. You weirdo.
Also allows SharedPreferences.apply() to be committed off the main
thread after returning from onReceive().
Change-Id: I27f975910e28f230ababcaeb551eb9a78ec4fc76
Certain fields in Animator are statics, like the list of current animations and the
main handler. However, since there may be >1 UI thread per process, these should really
be ThreadLocal variables, so that they are local to each UI thread. For example,
most animators will cause an invalidation in the view hierarchy, which can only
happen in the UI thread for that view.
Change-Id: I42be61c781ffac97b527f78ce1ffc2e0cdc42999
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
Retrieve the service again from ServiceManager on RemoteException.
Change-Id: Ie227b52019e7deafeab712af1addd6d957f7a8ee
Signed-off-by: Nick Pelly <npelly@google.com>
