GitLab

Merge "Cherry pick [Android WebView] Populate WebKit WebPreferences correctly in browser" into klp-dev

Merge "Cherry pick [Android] When toggling AX script inject, also set native AX state." into klp-dev

Cherry pick of https://codereview.chromium.org/23619089/

Bug: 10911684

Orignal description:
Currently Android WebView will push settings from the java side to the
renderer, but if the browser needs to read those settings back we will
use a default set from WebContentsImpl as we neglect to override
ContentBrowserClient::OverrideWebKitPrefs. This means that the browser
and renderer can see out of sync preference values.

Change-Id: Id466e29c009cb1d91cdab8eac8997de14f014657

This commit was generated by merge_to_master.py.

Change-Id: If451c530d0c6b67850aa33f17a128f39e3680d0d

This commit was generated by merge_to_master.py.

Change-Id: I8dd637c3a839c16cbab4d0b6b1edbfc557986168

Cherry pick of https://codereview.chromium.org/24559002/

Bug: 10911684

Original description:
[Android] When toggling AX script inject, also set native AX state.
When we enable/disable script injection, also update the flag that
says whether we should use native accessibility.

Change-Id: I6ff2ee7cb0309ec0f279178245056a6de3df560c

Change-Id: I82f33938413b8992d4900635033348cb78d0f784

Merge "Revert "Cherry pick [Android WebView] Populate WebKit WebPreferences correctly in browser"" into klp-dev

This reverts commit b855afc3.

Change-Id: I58ed8a8e207115ae043326c07b3e8cbb73642092

Merge "Revert "Cherry pick [Android] When toggling AX script inject, also set native AX state."" into klp-dev

This reverts commit 24d77bc6.

Change-Id: I4f37d9441af898cc703b47307c35e6379f561709

Merge "Cherry pick [Android WebView] Populate WebKit WebPreferences correctly in browser" into klp-dev

Merge "Cherry pick [Android] When toggling AX script inject, also set native AX state." into klp-dev

Cherry-pick of Chromium crrev.com/r225601

Conflicts:
  content/public/android/java/src/org/chromium/content/browser/input/AdapterInputConnection.java

BUG: 10523796
Change-Id: I2cb82de919e0012ea026f807e2a1e5edbf00a929

Cherry pick of https://codereview.chromium.org/23619089/

Bug: 10911684

Orignal description:
Currently Android WebView will push settings from the java side to the
renderer, but if the browser needs to read those settings back we will
use a default set from WebContentsImpl as we neglect to override
ContentBrowserClient::OverrideWebKitPrefs. This means that the browser
and renderer can see out of sync preference values.

Change-Id: I432f6bbe5a57ae0cdc1596554900b21953909494

This commit was generated by merge_to_master.py.

Change-Id: I4ead3c862c6fccc55b7e4fb8d20693746b3139e8

This commit was generated by merge_to_master.py.

Change-Id: I85686e2c9c2ba9db388d3554c0b323b5ed776857

Cherry pick of https://codereview.chromium.org/24559002/

Bug: 10911684

Original description:

[Android] When toggling AX script inject, also set native AX state.

When we enable/disable script injection, also update the flag that
says whether we should use native accessibility.

Change-Id: I7ab45f11ae44dd32f937e8828840a53180d4241c

Merge "Cherry-pick r218169 "cc: Layer::SetTouchEventHandlerRegion should SetNeedsCommit"" into klp-dev

Cherry pick http://crrev.com/23533051

> android_webview/ has to expose scroll offset operations in physical
> pixels while cc/ stores scroll offsets in dip pixels.
> Unfortunately the physical pixel values android_webview/ exposes are
> rounded so there is no such combination of rounding operations that
> allows for scrolls to 'bottom' in one corrdinate space to always be
> 'flush' against the bottom edge in the other. The most natural
> solution is to convert the scroll offset to the fraction of the
> scroll range.
> By using the max_scroll_offset value obtained directly from the compositor
> we're also removing the need to delay scrolls since the content size
> is always as recent as the scroll offset update.
>
> BUG=261239

BUG: 10741603
Change-Id: Ic70ebb913de4513925aa4ab6f077ee5d0625458d

Original review URL: https://chromiumcodereview.appspot.com/22891006

BUG: 10566215
Change-Id: Ifaf84163dd6d1a98ff9d3ed22a99171ce55a7514

Cherry-pick of http://crrev.com/24600002

> Always send DidOverscroll callback for android_webview.
>
> Some WebView embedders depend on overscroll notifications coming in
> even if the contents isn't otherwise scrollable. The WebView will
> not draw the overscroll glow in these cases but the embedder might
> chose to perform some action (like going to a different page) in
> such a case.
>
> BUG=internal b/8207890

BUG: 8207890
Change-Id: I2714f4fdd07e9498c01fd7d330e5ed26b3b32d7e

Bug: 10715395

This prevents double calling of didpagestarted and it enables
calling shouldoverrideurlloading for schemes other than http
and about.

Change-Id: Ia0eea9b82b88fb1c3bc5a6c56300f7f2a5fd3a1f

NPChannelBase is not threadsafe as it only expects to be called from one
thread in each Chromium process, but the Java bridge uses it from the
java bridge client thread and the renderer main thread, which are both
in the same process as WebView is single-process.

Ensure that each of the threads calling static methods of NPChannelBase
gets its own copy of the channel map and reference stack by using TLS to
store the global objects. Long-term we need to instead fix
http://crbug.com/298179 but this change eliminates the specific race
here.

Bug: 10492781
Change-Id: I2b18c991838b75eb6d481721a78e7dd73b7810f7

This commit was generated by merge_to_master.py.

Change-Id: I6db6411491130e38a47b7c4e28c55fbb5c9842bd

This commit was generated by merge_to_master.py.

Change-Id: Id94fb2308024a20dcac29481aab08ca7b38dacb0

Cherry-pick of Chromium crrev.com/222796.

BUG: 10460177

Conflicts:
	cc/layers/picture_layer_impl.cc
	cc/layers/picture_layer_impl.h
	cc/layers/picture_layer_impl_unittest.cc

Original description:

After releasing resources from the tree and recreating a renderer, it's
required for trees to reupdate themselves.  This is because layers drop
resources during DidLoseOutputSurface and PictureLayerImpl in particular
needs an UpdateDrawProperties to figure out which tilings it needs and
which one is high res.  (Without this, syncing a tiling from the twin
layer and then calling UpdateTilePriorities will call
MarkVisibleResourcesAsRequired, which may crash because there are
tilings, but no high res ones.)

This bug was missed in two places in LayerTreeHostImpl.
InitializeRenderer properly called set_needs_update_draw_properties, but
ReleaseGL and DeferredInitialize did not (although both recreate the
renderer).

As a sanity check, UpdateTilePriorities now CHECKs that
CalculateContentsScale (aka UpdateDrawProperties) has been called on
PictureLayerImpl between ctor/ResetRasterScale and UpdateTilePriorities.

ReleaseGL path was caught by:
LayerTreeHostTestDeferredInitialize.*

DeferredInitialize path is tested by new:
DeferredInitPictureLayerImplTest.PreventUpdateTilePrioritiesDuringLostContext

Change-Id: Ib05a128499e9ce2d668f4d4b1a05953d641cc685

Bug 10726773

patched in from https://codereview.chromium.org/23835019/ PS1

The workaround previously applied for Bug 10459904 left some cases
unhandled, so taking this as part of the full upstream fix
http://crrev.com/23835019

Original description
Support URL fragment resolution againt non-hierarchical schemes

Support URL fragment resolution against non-hierarchical schemes
As a result, data: about: etc now have 'query' and 'ref' components
parsed; as a result a new GURL::GetContent() convenience is added to retrieve
the spec with the scheme stripped off.

BUG=291747

Change-Id: Iae6f8cd77960b42956a1495c289fc074f3ae7e74

Bug 10726773

patched in from https://codereview.chromium.org/23549039/ PS7

The workaround previously applied for Bug 10459904 left some cases
unhandled, so taking this as part of the full upstream fix
http://crrev.com/23835019

Original description
Preparing to support fragment resolution against non-hierarchical schemes

Doing the first part of https://codereview.chromium.org/23835019/
in a preparation CL that should not make any tests fail.

BUG=291747

Change-Id: If4e1e7117d4153ee74f98b0f8ad0bab15e05ef10

Bug 10726773

The workaround previously applied for Bug 10459904 left some cases
unhandled, so reverting this to instead take the full fix from
upstream http://crrev.com/23835019

This reverts commit 69bf2d18.

Change-Id: Iba4f83ca7bffd1470c8aac68f25791b7a9b9e093

Add "Chrome/30.0.0.0" to the WebView's useragent to hint to servers that
the rendering engine is a modern Chromium and therefore it's okay to
serve "good" content to it. We keep the existing "Version/4.0" token in
case WebView-specific content is sniffing for it. The generic version
30.0.0.0 is used as the version of Chromium in the WebView does not
correspond to any exact Chromium branch at this time.

Bug: 10659017
Change-Id: I5c80509955ffb491f07b48cc5a0b0023ceb368a3

Merge from upstream https://codereview.chromium.org/23672055/

Bug: 10800319

Original description:
This gives us most flexibility in applying styles for content/
embedders.

No change in behavior.

Change-Id: I32d7d7621a98bfc24e753d8f6a18a79fbd8a2c02