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
* commit '18a259fe37861a78632a0667d746ea7d06356ced':
Fix for bug 4144936: [Proxy setting]: traffic to a bypass domain doesn't bypass proxy DO NOT MERGE
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
* commit '44e39d608cfddcbf56123480123822f26f20f259':
DO NOT MERGE Handle GET_POWER failures
DO NOT MERGE: Don't send pause again when coming back from full screen
DO NOT MERGE MediaScanner: Add special casing of WMP album art files to isNoMediaPath()
DO NOT MERGE MediaScanner: Fix bug in "no media" handling logic
DO NOT MERGE MTP: Implement GetThumb command
DO NOT MERGE MTP: Fix file descriptor leak in file editing extensions
DO NOT MERGE MTP: Add extended operations to support in-place editing of files
DO NOT MERGE MediaScanner: reimplement the ".nomedia" feature for hiding files from the media provider
DO NOT MERGE Fix media scanner uri handling.
DO NOT MERGE Revert "Remove permission android.permission.WRITE_MEDIA_STORAGE"
DO NOT MERGE MTP and media provider support for multiple storage devices:
DO NOT MERGE MountService: Fix running media scanner at boot.
DO NOT MERGE Fix deadlock in MountService
DO NOT MERGE StorageManager: Add getVolumeList() and getVolumeState() methods
DO NOT MERGE MountService: Add support for multiple volumes
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
* commit '29fa50be2484ed9d7a5e8075b764caa37b6494b9':
DO NOT MERGE : cherry pick of change Ieb7ae26b from master
DO NOT MERGE : cherry pick of change I0f9f2c65 from master
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
A cache control header containing both no-cache and max-age attribute does not
behave as expected.
Cache-Control: no-cache, max-age=200000
Will set expired to 20000ms seconds, ignoring the no-cache header. My
interpretation is that the no-cache header should not be ignored in
this case.
Change-Id: Iadd1900e4d2c6c0dacc6bb3e7b944cf78ca9b266
b/4088884 Backport "Remove content:// protocol handler in web browser"
to Gingerbread
It's a manual cherrypick of
https://android-git.corp.google.com/g/#change,87278
since a lot has been changed in bettween.
Change-Id: Ic8e3a419571f535bf983f32cd02181ca66d19319
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
