To allow use of the native CursorWindow class outside of the core framework jni
Change-Id: I72e8dcb91a2c691130c33cdfd9a25d343da1c592
Signed-off-by: Mike Lockwood <lockwood@android.com>
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 fixes a bug in commit https://android-git.corp.google.com/g/#change,52518.
Updated index to be zero based when passed around and off by one error on
resume. Note that previous commit changes how DumpRenderTree dumps titles.
This might affect the results of layout tests.
Change-Id: I3d6989d71c336f90168e38c994dd36743bda365c
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
Merge commit 'f69fd4dd481c10749a8651ab6c9cfda1dea68297' into kraken
* commit 'f69fd4dd481c10749a8651ab6c9cfda1dea68297':
Doc change: Suggest min keysize of 2048 for keys.
