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
Normally this wouldn't happen as a new picture should come after
webcore has initialized. However, now that a view state can be loaded,
setting a new picture needs to be delayed until after everything has
initialized.
Change-Id: I823bc17eb939eab0436d7a398ebcbe849c0fb945
Framework for serializing the view state
Still needs to prevent sending messages to webkit (pinch
zoom doesn't work correctly as a result)
Change-Id: Ic3f8fe19b27ff1f841b556e87f582dab2a6d903b
In full screen mode, the play message can be trigger, that means we can't
assume that the play message only comes from inline mode.
bug:4498120
Change-Id: Ibf85bb74778df207a6ce786dc63b0845356a281c
This fix will only set the overview scale in case the screen
is rotated from landscape to protrait, since in this case
the overview scale will be smaller and need explicit setting.
For the other way around, there's no need to set and it has wrong
effect for mobile sites.
issue: 4343683
Change-Id: I92cbf848bc2ed4184bd0c6b67992ff5cbc633c9f
Basically, the GL texture bound with Surface Texture is not a singleton any
more. And the Surface Texture will be recreated every time a new video starts.
This can help to recycle the decoder's memory while using the GL texture to
show the screen shot.
The corresponding webkit change is: 112500
Change-Id: I3c35f6a0abc70b9039c316ca82b236c797d81c7e
The InpuType from <input type="email" /> has been broken.
Change-Id: Ie37de69682410cdd58c29910d483e924f5b614b6
Related-Bug: 4490948
Cherry-pick: Ibd7f2977a177f1d97e3a29ac44220e5136bbd653
Adapt to change in the way MockWebServer sets up CONNECT proxies.
git cherry-pick --no-commit c7e2feee5e7908a019a0de91123c1feb9bdc38bc
React to move of Base64 in libcore
git cherry-pick --no-commit 119f7ebdd1f8df3a8ff8e3b8056bff725d569253
Expose and document android.net.HttpResponseCache.
git cherry-pick --no-commit 7b73f0fdb8c032a65c55610541d66385bd8bcbe6)
make update-api
Change-Id: Ieb48b304ea38ee8c2ec01e860d99b1404583889e
Refire the redraw event if webkit wasn't ready
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: I70fcf652cc854f995885c58b55d58ecf75734ab8
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
As using wide viewport implies fixed viewport.
Also fixed an issue for mobile page viewport calculation.
issue: 4343683
Change-Id: I669618f8522377ff97317bb1b78700ad40e51bb3
This will simplify viewport logic; and currently Clank behaves
the same for phones.
issue: 4343683
Change-Id: Icddc23cd5b12f9820c611dbf66c9772f147baf4b
* 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
