WebKit calculates its scrolling destination coordinates relative to the
visibleRect that WebCoreViewBridge provides it. That visibleRect is stored
in WebViewClassic as mScrollOffset. When a titlebar is displaying, the
coordinate conversion from content to view fails. This conversion is used
in many other places and seems to function perfectly fine for them, so I've
concluded that while it may be the wrong tool for this particular job, it is
the correct tool for many others. As a result, I've left the conversion as it
is and simply fixed the function that WebKit calls to programatically scroll
the content. This fixes all of the programmatic scrolling issues I've been
seeing with find-on-page without breaking anything else.
Bug: 5470588
Change-Id: I50d3af4dd8a7fbd2d04bbb41e38f3e6947fbb46a
Bug: 6109044
Tab keys are handled via canTakeFocus & takeFocus (new path)
Arrow keys are handled by seeing if the keyDown was unhandled (similar to old path)
Change-Id: I825de102de31443b1383a8126992c65a4957dcce
Instead, just reference the authoritative docs in WebView
Also add @Override for all WebViewProvider overriden methods.
Change-Id: I02adf5dffed9dca3934c03c5cd93f005773e406e
Bug 6097462
If paste window is shown before the insert thumb, an NPE
would be thrown. This will be fixed fully later when the paste
window is showing up only at the proper times rather than every
time the insert thumb is shown.
Change-Id: I91eec7c28fc64a2274f5c3cd36784fedcae055ca
Splits interface and implementation; all client calls are forwarded
to an abstract WebViewProvider interface, and the existing implementation
moved into the WebViewClassic implementor of this interface.
Originally taken from a snapshot from the development branch, by:
git diff HEAD 9a4c328a54cc05e5 | git apply
- but then rebased to keep up to date with master
Interdepends on webkit and Browser changes:
https://android-git.corp.google.com/g/158979https://android-git.corp.google.com/g/167911
Change-Id: I91403f32654ff308934e95c832d17b292a7d9b2e
This is done as its own step to make follow up patches easier on the eye.
(mostly implemented with eclipse refactor magic)
Change-Id: I23a9c1cbc5bba9a492e7e2ef1ddd275d84bec057
Bug 6083776
While WebKit limits the length of a field with maxlength, the
InputConnection can get out of sync with it when it doesn't
recognize that the characters haven't been changed. Adds
maximum field length to WebViewInputConnection to limit the
characters typed.
WebKit Change: Ie02f82a3f5b3527c378938d93bac2dece802af26
Change-Id: I135871db7809e8dc28a3ad8d3aa852976a274555
Optional titles will only be displayed in the CAB if they entirely fit
instead of ellipsizing.
Fixes bug 5821883
Change-Id: I0cfd6d4fd34a4fa9f520499d577706da30606811
When an <audio> tag has the loop=true attribute,
Webkit tells us to seek back to 0 before we are supposed
to have stopped the stream. But by the time that the message
gets back to the Android MediaPlayer java side, it's already
stopped. So after seeking, we play() again if the player is in
the COMPLETED state. Change the code to do this and handle
the case that we call play on a COMPLETED stream
(resetting internal state, etc).
Note that this has the side effect that we will start playing
the stream after any seek on a COMPLETED stream - e.g. dragging
the slider thumb on the progress track after the stream is
finished.
Bug: 5461143
Change-Id: I6cf4d46d9a1985caf9f9ab85dbcf65535c8dcd77
