This CL is one in a series of CL's intended to remove the zoom
logic from WebView. This CL focuses on refactoring the initialScale
variable as well as the onSizeChanged() and NEW_PICTURE_MSG portions
of the code.
Change-Id: Id44bce50378aa7cdfc1c8110818e18500679c517
http://b/2671604
If an Exception occurs when storing the file treat this as an error
and always fail to try to prevent corrupted pictures to be stored to
the file system.
Close files if they were opened, the caller might want to perform other
file operations on the file and if it is still open these may fail.
Change-Id: Ic68596b5c745bbe413096c22684c388e853a7643
pick bad5ede Revert "Refactor the on-screen zoom controls into a separate class."
one part of a series of CL's that is intended to refactor all zoom
logic into the ZoomManager.
Change-Id: I6260c7d2daade4861df1296c9db364ee2a892bd0
http://b/2671604
Rather than just storing the name of the file that the user chose in the file picker,
store the full path to the file. That way we can open it using the file API and still
extract the filename itself by simply chopping off all but the last path segment.
Change-Id: I25f2fe818deda8ca848f0da02cf45ae97d2127fb
highlight.
The new setting, supportTouchOnly(), is currently not
fully implemented. It is overloaded with mLightTouchEnabled
for short term testing. To test the feature, please
use the "Enable Light Touch" in the debug settings.
When supportTouchOnly is true, we are not using nav
cache to display the yellow ring. Instead we show
the gray rectangle(s) based on the calculation from
WebKit. When short press happens, we current use 0
for mMoveGeneration so that it will trigger WebKit
to use the same point when it calculates the highlight.
If you turn on NavDump in the debug settings, it will
also draw the fat point where you tap on the screen.
Known issues, it is not fully synced with IME. If you
tap a text input box also in focus, the yellow ring
will show up. If you leave the text input field, the
IME is not dismissed. If this passes the user tests,
we will make a special mode and fix all these issues.
There is another matching CL in external/webkit
This layout test is currently failing due to timing out in DRT.
The issue is that the test sends a down, up, down sequence quickly. For
each down event, we post a PREVENT_DEFAULT_TIMEOUT message to the
WebView's message handler. WebCore responds to the first touch event and
we update the mPreventDefault state variable correctly. The second touch down
resets mPreventDefault as it's the start of a new touch sequence and a second touch down is posted
to the WebCore thread.
At this point we still have the first TIMEOUT message in the WebView queue. The problem occurs
when the WebView processes this timeout message before the WebCore thread processes the second
touch down message. In this case the WebView clears the WebCore thread's message queue and instead posts
touch cancel events, erroneously removing the second touch event. This timeout message should not have been
processed as it was associated with the first touch down that had already been completed. Without the
second touch the test never completes.
The fix is to remove PREVENT_DEFAULT_TIMEOUT messages from the queue before starting
a new touch sequence.
Change-Id: Ief054239529d710a79a0e58a589bd7a92434dbf2
This CL is #2 of multiple CL's to remove the zoom code
from webview and place it into webkit.ZoomManager. Each
commit is only part of the entire refactoring so there
are many ZoomManager.* variables still referenced from
WebView.
Change-Id: I21f6517dff46b65a277bc67120ffabe043098e5e
http://b/2671604
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
