This is causing issues with MotionEvents built by various tools such
as DRT. The check itself doesn't seem strictly necessary, and it is
easier to remove the check than fix all the tools and tests
Change-Id: I74bf85307956b5858042fbe23f87ed2b87132f17
- remove final from classes which we will need to provide subclasses
in future: CookieManager, GeolocationPermissions, WebIconDatabase
and WebStorage. None of these have published constructors,
so applications cannot subclass them anyway.
- Also convert some protected members of JsResult to private, as its of
no use to legal subclasses, and applications cannot subclass it.
Change-Id: Iaca9d2db31e25853b6c55feae41d9e7774087479
1. It wasn't clear that SupportZoom doesn't affect WebView's
zoomIn / zoomOut methods.
2. It was easy to misread that to enable "pinch to zoom" one
needs to hide zoom controls.
Bug: 5461416
Change-Id: Ic8afd22ae0f36e53b9f4724e95ac55c766f58af5
Plumb the value of the "capture" attribute through the framework
down to the embedder.
Requires a change in WebKit
(I0a921be31fda79a43c05da4fe22d9c808d92709c)
and Browser (I38dfe2df043fdba1388384dbd3b5370737eb38e5).
Bug: 5771207
Change-Id: I494adc1274ca21ce8fe52a6c7b6b758217927e66
WebStorage and GeolocationPermissions are not intended for direct use
by application code. Existing APKs using this will still work (as well
as they ever could have), but this change will cause a compile break if they
move to SDK >= 16, which should be fixed by using getInstance() instead.
Bug: 6238010
Change-Id: I75789cc260c8fe005c42942bc81483193cc54f17
The majority JsResult and JsPromptResult are simple data-carrying &
callback classes. Extract the WebViewClassic specific parts dealing
with WebCore thread and CallbackProxy and decouple via abstract interface.
Bug: 6238755
Change-Id: Ibafd18910725f0875e3b59c1b2078173c102cdec
This method is already @deprecated in docs anyway.
StrictMode.noteSlowCall can help apps discover the error.
Change-Id: Ie131d938b0dd32f85ec1886e2139ce3c3f511209
Bug: 6317798
Stuff that's better:
1. We maintain two queues in a way that ensures that WebView and
WebKit both see consistent streams of events, even in cases
where WebKit times out. We send ACTION_CANCEL if necessary, etc.
2. All pointer events go through the same channel, including
hover and click ("touch up") events, to ensure correct ordering.
3. Given that the input events are in a separate queue, we can
force execution of all of these events whenever we like, making new
latency optimizations possible.
4. The entire history of each touch event is sent to the web
application to enable smoother interaction.
5. The web application may choose to intercept a touch event stream
at any time by issuing "prevent default". Previously, it could only
prevent default on the initial down event. The new behavior is more
standards compliant.
Change-Id: I42d2d045e7d44af7c54b29570f188b7400d91d4e
Multiple paths were redundant, as they both synchronized the layers, and drew
the base if needed.
Depends on external/webkit change: https://android-git.corp.google.com/g/#/c/179965/
Change-Id: I1c355510f6edda4631190f2d26df8171e795a6ac
We now allow processes that currently have stopping activities to
be managed as if they were done stopping, so that memory trimming
can be done before the process goes to the background. Hopefully
this will reduce cases where the processes goes to the background
and immediately gets killed, but wouldn't have had to be killed if
it had a chance to trim its memory.
Also change window memory trimming to always do the aggressive
trimming when memory is critical, even if not on a low-end device.
And tweak web view trimming to not trim for foreground UI events.
Change-Id: I241b3152b52d09757bd14a202477cf69c9b78786
