GitLab

Disable NOTIMPLEMENTED() as the messages generated are not actionable by
app developers.

Bug: 18291756
Change-Id: I8d52c69874fe2818ac58235d9441936798dc60d6
(cherry picked from commit bf063fe8)

This commit was generated by merge_to_master.py.

Change-Id: If5c41c8901c327e0abeb154e756e609eec2d8c0d

This commit was generated by merge_to_master.py.

Change-Id: I20d82af796d2bd2787e3300a2b35ea1b00216a26

This is a clean cherry pick from:
https://crrev.com/06091eaf4543692caf7a0bcaf5c3a550dfca7078

We need to do this because in the Android WebView pop up flow, the
native WebContents object could possibly have received RenderViewReady
IPC message before the CVC is constructed and starts to observe the
WebContents.

BUG: 18527015
Change-Id: Ibccac065c0607bd2ec45c0a9e152128ea8805b7e

Cherry pick from:
https://crrev.com/a43a08a85da0a2d2ed78a850fa9f8efe8c0028b9

Original description:
Detecting if we're using synchronous compositor is unreliable because
the synchronous compositor could be created either before or after
RWHVA constructor.

Instead, we can detect if we're using browser compositor in RWHVA. And
this can be done reliably at RWHVA construction time.

Conflicts:
  content/test/run_all_unittests.cc,
  content/browser/renderer_host/render_widget_host_view_android.cc

BUG: 18377042
Change-Id: I5ad377de0c8651a76eb51776eca7e7ad3fd3e9cd

Cherry pick from Chromium:
https://codereview.chromium.org/751453005/
Only the fix part from the original CL is cherry picked. 
The other changes in the original CL are all tests.

Original description:
An empty clip rect of a render surface does not necessarily mean
the surface is unclippped.

BUG=435797

BUG: 18343246
Change-Id: I56b8f2d557b21aa75619157e611ab4da9bd4688c

Cherry pick from Chromium:
https://crrev.com/d1d74981ce7baa010996c82a7b3423d06af466f1

Original Description:
When a paste or cut operation is performed in an editable region, and
the action bar is dismissed, the IME state should be preserved. Ensure
this by always using the editable region bit when clearing the selection
upon action bar dismissal.

BUG=435810

BUG: 18200283
Change-Id: Iefe239341010236ea6833c98ade34499970aae62

This commit was generated by merge_to_master.py.

Change-Id: Ia17c23f18c98496f73176f545e8331805640ccec

This commit was generated by merge_to_master.py.

Change-Id: I1bb301dcfe74249d8b66fb60ba577e9095c86b8d

Clean cherry-pick of chromium
crrev.com/18abdf1afb8034be81213b23d9e05d34e92bc8d3

BUG: 18386625

Original description:

This is a small webview-specific workaround that affects all drivers.
Will need a better driver/version specific workaround later.

Change-Id: Iec566f9f166397a104badb8b549cc59e6173faac

* changes:
  Update volantis workaround to cover L mr0.1
  Cherry-pick: Workaround NVidia eglWaitSyncKHR bug
  Cherry-pick: gpu: Use egl client wait if server wait not available

This patch fixes a regression from K to L. Tapping the back button
while in fullscreen should exit fullscreen instead of the current
activity.

BUG:17985005
Change-Id: I7a5eb4edebb54ce1e7d6a2b578a87dd7e7de9dbf

Bug: 18388001

Clean cherry-pick from
  https://crrev.com/200b2f027ce820425e37b08ed8b4e5dc84928276

Android platform provides a local proxy that also handles PAC proxy
resolution. The CL below modified enabled chrome network stack to start
using V8 proxy resolution on Android platform:
https://codereview.chromium.org/573013002/
however webview cannot use V8 proxy resolution since Webview is significantly
different from chrome: Webview is single process vs. chrome is multithreaded
and use of V8 isolates creates concurrency problems with Blink's use of V8
isolates.
For now, we want to establish the prior behavior for android webview and
consider making changes to v8 proxy resolver in future.

BUG=432539
Committed: https://crrev.com/200b2f027ce820425e37b08ed8b4e5dc84928276
Cr-Commit-Position: refs/heads/master@{#305166}

Change-Id: I58becc2acf369956df6c458df13a53dac05caff3

BUG: 18412138

Change-Id: If713c5fb10c2d7317c08f1d85249f621161ed982
(cherry picked from commit 293eed332e8b9da195b229c36299d66f1604fc04)

Conflicts:
	gpu/config/gpu_driver_bug_list_json.cc

Clean cherry-pick of chromium
crrev.com/ba561e7fb76fef1a6dfff772b08bd6dde5c94bc9

BUG: 17690996

Original description:

Workaround is to fallback to client wait.

Change-Id: I8d6b41f5bc94307faecffe1401b660a3a722e24d

Clean cherry-pick of chromium
crrev.com/bf634aa33aa21ce25ef680bca6305b9ad64acfbc

BUG: 17690996

Original description:

Check for EGL_KHR_wait_sync extension before calling eglWaitSyncKHR. If
extension not present, fallback to EGL_KHR_fence_sync and
eglClientWaitSyncKHR.

Change-Id: Ia3dad04d468ffebb88b549adb06a310f933d9b5b

Bug: 18297802

Cherry-pick disable channel id

Android webview does not use channel id since there is no API
to share channel ids and this would break some apps that use
different network stacks. This change is to explicitly
disable it.

BUG=433427
internal bug b/18297802

Review URL: https://codereview.chromium.org/731593003

Change-Id: Iefd0f61c922227d562667f4a53f0bb35b03b444a
Cr-Commit-Position: refs/heads/master@{#304316}

Clean cherry-pick of chromium
crrev.com/d51117a99a4e023e791134185c6db12b28028a1d

BUG: 18283959

Original description:

Chromium shares a message loop with Android on the browser UI thread.
This can cause problems when the associated Looper has a sync barrier,
preventing posted Chromium tasks from being dispatched until the
barrier is removed. Make this sharing more fair by marking all Chromium
Message tasks as asynchronous, avoiding stalls when there is a sync
barrier.

Note: This change was originally landed in crrev.com/512333002, but was
reverted to gather more data about sync barrier impact and investigate
alternative solutions. The investigation determiend that this approach
is fine for the near future, though it will likely evolve in time.

Change-Id: I9879a9c1bdad0dcec12c2bbee62356a5b12d9596

Cherry-pick: Revert of [Android] Experimental sync barrier detection for tracing (patchset #6 id:100001 of https://codereview.chromium.org/575103002/)

Cherry-pick of chromium
crrev.com/adefc40cb9652a2ea046bbdbef223d881f4a7463

Conflicts:
	base/android/java/src/org/chromium/base/SystemMessageHandler.java

BUG: 18283959

Original description:

Reason for revert:
Barrier detection is no longer necessary, see crrev.com/512333002.

Original issue's description:
> [Android] Experimental sync barrier detection for tracing
>
> When an Android View is invalidated outside of frame dispatch
> (animation/input/draw), a sync barrier may be inserted into the shared
> UI thread message loop. This effectively blocks dispatch of all Chrome
> tasks posted to the browser UI thread for an entire frame (or more if
> the View is continually invalidated).
>
> There are currently no easy or even automated ways to avoid this
> untimely invalidation, and judicious coding can only take us so far. As
> an intermediate assist in debugging the issue, use reflection and a
> crude form of MessageQueue inspection to trace known cases where the
> MessageQueue is blocked by a sync barrier.
>
> Note that this detection is not perfect, neither is it exact, but it's a
> solid proxy for informing traces about such pipeline stalls.
>
> BUG=407133
>
> Committed: https://crrev.com/85bceaa6e05ee1bf42ac220ddcbb50ca268c1ea4
> Cr-Commit-Position: refs/heads/master@{#296249}

Change-Id: Ie92ab895b864bf466ac092a1a1b7fdc80a8fd3ce

detached

Bug: 18373995

Original Description:

PopupWindows are used to render text handles in WebView. As these popups
are drawn outside of the web contents View hierarchy, it's possible that
their visibility becomes unsynchronized with the WebView itself. For
example, after the WebView has been detached from the window but
before it has been properly disposed of. Address this by overriding
handle visibility when the (content) View is detached, restoring it
only after re-attachment.

BUG=430859
(internal b/18066784)

Change-Id: I43b5ff63368384c3ff30ceece7ddd86aa0a4b738
Committed: https://crrev.com/0563c2785d0b1e62793ffb0f9dc3ac178559aeaa
Cr-Commit-Position: refs/heads/master@{#303987}

Bug: 18200283

Cherry-pick https://codereview.chromium.org/713493003.

Clear the selected text when hiding the handles and the desired
behavior is to "unselect all on dismiss".

BUG=430859
internal b/18200283

Review URL: https://codereview.chromium.org/713493003

Change-Id: Ie8d751774c6341054f0c1b8d4cca91ba6877e373
Cr-Commit-Position: refs/heads/master@{#303946}

Cherry-pick of chromium
crrev.com/2c8b61a4db617427448947ff740ba002da1a9644

Conflicts:
	cc/resources/picture_pile_unittest.cc

BUG: 17965814

Original description:

Previously, there was a hack/optimization where when shrinking a pile,
there would be no invalidations.  Unfortunately, this hack's time has
come due.  When zooming out, recorded pixels outside of the pile's newly
shrunken bounds can get used, causing pixels from old frames to get
incorrectly sampled, causing bogus hairlines.

To fix this, issue invalidations for previously exposed content in the
same way that invalidations are currently issues for newly exposed
content.

Change-Id: I3287e7e2261328a37781bf58da97ac4b7e60cb73

Bug: 18066784

Original change description:

Previously, selection handles would be hidden when the content view
became unfocused. This approach worked fine in Chrome, where the focus
model is predictable, but led to undesirable consequences in WebView,
e.g., the handles never being shown. For now, avoid making any kind of
visibility changes to the handles when the focus changes, ensuring
handle visibility is consistent with the selection.

Also ensure timely cleanup of the PopupTouchHandleDrawable Java object
after its native counterpart has been destroyed.

BUG=430859
(internal b/18066784)

Change-Id: I1741f81c5a12f71c053796cde37989366d2fcf10
Committed: https://crrev.com/1ba4ec56cb8f8e76f5d0cd37db09ebe41129c9c8
Cr-Commit-Position: refs/heads/master@{#303728}

Bug: 18066784

Original change description:

If the ContentViewCore container view is not focusable (which can
happen when it's emebedded in an app via android webview), we
were clearing the RWHVA notion of focus when the RenderView was
swapped out. As the view is never focusable again, chromium never
considers this view focused and as such, text selection did not
function.

We support this type of container view by always treating it focused
from Chromium's point of view.

BUG=430859
(internal b/18066784)

Change-Id: If08372c93ff0c87b483f0b408f04247764db2c56
Committed: https://crrev.com/9074d9fc9119ef4d2223f6c993d1a1b67a0bea7c
Cr-Commit-Position: refs/heads/master@{#303071}

The size update races with the page load creating the opportunity
for the page to observe the initial (0,0) renderer size. This patch
addresses the issue by sending the initial size together with the
RenderView creation request.

BUG=424205

Review URL: https://codereview.chromium.org/659093002

Cr-Commit-Position: refs/heads/master@{#303775}

Conflicts:
	chrome/test/data/extensions/platform_apps/web_view/shim/main.js
	content/browser/renderer_host/render_widget_host_unittest.cc

BUG: 17892238
Change-Id: I11dca7e962421d46734d2122ec79bc501a2db09d

Bug: 18222974
Change-Id: I42e787b6205ec3c3764ec5076e2391e4ec4e4deb

Conflicts:
	android_webview/java/src/org/chromium/android_webview/AwContents.java

This commit was generated by merge_to_master.py.

Change-Id: Icdd8bd8652dd63d1358a2022e1567051d48f760e

This commit was generated by merge_to_master.py.

Change-Id: If9c0c09d8c3a3121b5e75ae9c4c446e4e4baaae6