The way that smooth scrolling is implemented in the Browser,
repeated requests to scroll by a certain amount do not add up
to one large scroll by the cumulative amount. This makes
the mouse wheel unusable on large pages because the Browser
will scroll at a more or less constant rate no matter how often
the wheel is turned.
The fix is to not animate scrolls when using the mouse wheel.
Change-Id: I23c05cdd2383944b8730deb225b7f3f57f1729df
The InpuType from <input type="email" /> has been broken.
Change-Id: Ie37de69682410cdd58c29910d483e924f5b614b6
Related-Bug: 4490948
Cherry-pick: Ibd7f2977a177f1d97e3a29ac44220e5136bbd653
If webkit wasn't in a drawing mood, post a WEBKIT_DRAW event to
assure that the update is not lost.
bug: 4474358
Change-Id: Ib0c4cedb10f58821f95c439824c30043a906f8b8
When the version is reported as a codename, use the previous version
in the user agent string.
Bug: 4347787
Change-Id: I4ed804a7334d6ca242446176ff042c4ac7938a0f
The current browser pause/resume logic uses an integer count to track
the pause/resume behavior, which is mostly working fine in phone. The interger
count is usually 0 when browser is paused, and its value is usually 1
when the browser is resumed and will trigger any delayed timer.
But in tablet, where tabs can be easily created/switched/deleted, this
logic will not work well and sometimes cause resources timers get stuck.
For example, in case multiple tabs are created, and you reload one of the
tabs, when it's almost finished, switch to another tab, and hit home or power
button, at this point of time, the browser will be suspended at
Controller.java::onPause, hence the integer count will be 0; but since
the other tab is also finished after the pause, the current logic at
Controller.java::onPageFinished will call pause timer again, which will make
the integer count to be -1. Before the time the browser is resumed, it's very
possible some tabs will have some resources, such as images/flashs,
scheduled to be loaded, these will be in delayed timer in
ResourceLoadScheduler.cpp's m_requestTimer.
Now when the browser is resumed, the integer count will be 0, which will not
trigger delayed timer. Then all the new timers will be stuck as well since
old timers are not executed yet.
The fix is to simplify the pause/resume logic by just using a boolean variable
instead of error-prone integer counting.
issue: 4177932
Change-Id: Id10af9298c7be1f82222d0b94c34c5dc68403630
Switching back to use the setDataSource with Uri, which can handle both the
file and http path correctly.
Change-Id: I5bfc1d01a8de0a4f8640ffceafbc17984833097a
When we enter full screen, the inline video has been paused.
When we re-play in the inline mode, we don't need to paused the previous video,
which is the full screen one.
bug:4259109
Change-Id: I577edf43563116b0d1a9266d741e6a8aabbca779
In full screen mode, we shall not always rely on the auto start info.
If the auto start is false, it will prevent the video from playing.
The auto start should always happen inline mode when prepared.
If we switch into full screen mode while playing, we will also do auto start.
bug:4260063
Change-Id: I4b13c30b1f2c219951dc8edd659e221a21c86c2b
Pre-queue WebView touch events as we send them to webkit so that we
can run them through WebView later if webkit or hosted plugins go out
to lunch.
Change-Id: Id4e9f56beeb0c1d55e77233423844b15f6f00aef
The addition of the HW accelerated logic causes us to manipulate the
zoom scale factor in the zoom manager two additional times. These
manipulations occur after the mZoomScale has been set to zero is how we
previously tested to see if a fixed length animation was occuring.
bug: 3451126
Change-Id: If2992adbe36fa471bb1bb5013495e1adc74b5fab
In the case that a touch event is passed to WebKit then back to
WebView, the coordinates will be converted from view to content
then back to view and the convertion could lose some accuracies.
For a flash content that only consumes TouchDown, all the
TouchMove events will go through this path and each time, the
data becomes more inaccurate. Even worse, the TouchMove event
updates the mScrollX/Y which will then be used for the convertion.
The effect amplifies really quick and the scrolling looks jumpy.
The fix is just to store the original view coordinates when pass
the event around.
Change-Id: Ie1424d7cfc6272348b194732e97168efe2dcf17b
WebCore is too slow
Make sure that we can recover properly from a bad gesture with missing
events that never come back from webcore. Lower timeout to 1 second.
Confirm movement on touch event enqueue so that we don't get phantom
taps or long presses when webcore is slow to respond.
Add sanity check in ScaleGestureDetector to end a gesture early on a
bad MotionEvent stream rather than throwing up.
Change-Id: I69690409d7edd6b4320dbcf3b052aba4023360fe
This is the Java side code change for b/3392594.
It adds an action index into the touch event data and pass it
to the native side.
Change-Id: Ibb393e62a590d0fff1dd3172041748e2b10501d6
flashplayer in browser
Fix an issue where gestures weren't being fully canceled by webkit to
the multitouch detector. This will prevent ScaleGestureDetector from
attempting to resume its regularly scheduled gesture already in
progress.
Change-Id: Id4881eeb1df8414dfa23174481bd7dc70fd08fee
