Merge commit 'e64256d610ec5ea3df5db8a24333a6ce98b83d49' into froyo-plus-aosp
* commit 'e64256d610ec5ea3df5db8a24333a6ce98b83d49':
docs: revise webview description and add info for targeting screen densities
This CL is the first in a series of CL's that will extract the
zoom code from WebView and put it into ZoomManager. This initial
CL only extracts the on-screen zoom controls and required variables
into the ZoomManager. Since the on-screen controls are well defined
I put them into their own class called ZoomControls.
All of WebView's zoom interactions are handled by the ZoomManager.
The ZoomManager can then handle the request internally or as in the
case of on-screen controls pass the request to another class.
Change-Id: Icfc91ed0456c88d633249c26b9afc7dd216f75a1
http://b/2671604
Merge commit '336d7dcb105a43ee4de51fd0f26f277c63662f02' into froyo-plus-aosp
* commit '336d7dcb105a43ee4de51fd0f26f277c63662f02':
The default AlertDialog allows cancel. But the default
JSConfim doesn't have a cancel listener. So when
user cancel the dialog, we do not wake up the WebCoreThread.
The same code is already done for JSPrompt dialog correctly.
Fix http://b/issue?id=2679139
Remove mFindHeight, and the associated adjustements. It
is no longer needed because the FindDialog is no longer
on top of the WebView; instead, the WebView is resized to
accommodate it.
Do not take focus if the user touches the WebView while
Find is up.
Add a (hidden) getter to check to see if Find is showing.
Requires a change to packages/apps/Browser
Change-Id: I08cedb02d29eeeaac6860aa0933ccab43ed5c39f
WebView.java:
If the cursor and focus are on a contentEditable element, allow it
to handle navigation keys and shift rather than the navigation system.
Also rename method for its new more general use.
WebViewCore.java:
Change the name of MOVE_OUT_OF_PLUGIN to a more generic name, and
fix a bug in the message being sent.
Bug 1788820
Requires a change to external/webkit
Caveats:
Does not ensure that the caret remains on screen. Frame::revealSelection
is called, but we ignore it for other reasons. Need to investigate that.
The cursor will blink if the contentEditable node has focus, even if the
user has not clicked on it or has moved to a different input field. Further,
while in this state, the user can input text.
Change-Id: Iaa935363fd324925a1e338418d32f362f58c4494
from http://code.google.com/p/android/issues/detail?id=4638
If you try to use a WebView to open an image (of any type)
that is stored in your project's assets/ directory the image
will be written to the screen as text (instead of drawn as
an image) if the filename contains a space.
The problem stems from MimeTypeMap, which determines the
file type from the url. Spaces, represented as '%20'
are not included in the list of acceptable characters for
an image file name, causing the image to be treated as plain
text. I am remedying this by adding '%' to the list.
Change-Id: I29e3da57f3cdaa63ed60b1e6977ba62a0dd108e5
Update mLastTouchX/Y on every drag. This prevents the creation of
dead zones that the user has to drag back out of at the edges of
a document.
Change-Id: I348d96dfd3907dba7c6ddd86b678329d65063ba9
from WebCore, then we would enter the ACTION_UP handler and cancel
pending touch events in WebCore's message queue. This cancellation
was orginally needed for Flash but the touch model for Flash has now changed
and it's no longer necessary. In the case of the layout test controller
the events do come very fast, and we were hitting this case so
WebCore was losing the events that got cancelled meaning that the
JS touch callbacks weren't getting invoked.
This was exposed by fast/events/basic-single-touch-events.html.
Change-Id: Icea09fb55a5b77f7ab9c19473cfa5ae272867a9a
we can continue the interrupted request to support
streaming the content even with a brief disconnection.
Note: we don't update the headers for partial content
as the headers we care should not be updated. See
a list in chromium/net/http/http_response_headers.cc.
We currently also don't support cache for partial content.
Fix http://b/issue?id=2616477
we switch to use the layout size. Otherwise it will
first use the old dimension which can exceed the
limit, which in turn causes the Browser to crash.
Fix http://b/issue?id=2616263
The call was originally added to fix bug 2431351, where touching
a <textarea> sent a message with the new selection, but the UI
thread had not yet updated the WebTextView, so the new selection
was ignored. However, since then,
https://android-git.corp.google.com/g/#change,45476 was submitted
to pass the selection and open the keyboard at the same time. So
when UPDATE_TEXT_SELECTION_MSG_ID is received, we no longer need
to worry about the case where the WebTextView is not set up yet.
Bug 2600847
Change-Id: I19eb102a7188e6edafaa5ac17b19ebd4ab5764f0
