GitLab

These days, the SDK is already checked out by DEPS in
src/third_party/android_tools/sdk, so trying to download it again from a
different location at a later stage does not make much sense.

R=peter@chromium.org,bulach@chromium.org,craigdh@chromium.org,frankf@chromium.org

Review URL: https://chromiumcodereview.appspot.com/23621025

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@222121 0039d316-1c4b-4281-b951-d872f2087c98

Review URL: https://chromiumcodereview.appspot.com/23640009

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@222120 0039d316-1c4b-4281-b951-d872f2087c98

BUG=

Review URL: https://chromiumcodereview.appspot.com/23458013

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@222119 0039d316-1c4b-4281-b951-d872f2087c98

BUG=276900

Review URL: https://chromiumcodereview.appspot.com/23484018

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@222117 0039d316-1c4b-4281-b951-d872f2087c98

Both OSX and Views' App List implemetnations use a kIconDimension of
32x32 for icons shown in search results. This change uses a prescaled
32x32 icon asset for attaching to the "Search in webstore" result type,
rather than rescaling a 128x128 icon asset to 32x32 each time it is
shown.

BUG=285735
TEST=On OSX, perform a search in the app launcher that shows a webstore
search option - it should show the webstore icon next to it.

Review URL: https://chromiumcodereview.appspot.com/23494037

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@222116 0039d316-1c4b-4281-b951-d872f2087c98

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@222115 0039d316-1c4b-4281-b951-d872f2087c98

http://build.chromium.org/f/chromium/perf/dashboard/ui/changelog_blink.html?url=/trunk&range=157453:157457&mode=html
TBR=
BUG=

Review URL: https://chromiumcodereview.appspot.com/23498024

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@222114 0039d316-1c4b-4281-b951-d872f2087c98

Interfaces only at this point.  Implementation to follow.  API mirrors
that which is provided to the CDMs in http://crrev.com/221019

CanChallengePlatform() can be synchronous since it will just check a
command line flag passed to the process.

BUG=270294
TEST=none
R=ddorwin@chromium.org, dmichael@chromium.org

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

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@222113 0039d316-1c4b-4281-b951-d872f2087c98

This change includes intercept code to dispatch eject calls on
MTP devices for all platforms. By and large, MTP devices don't need
specific ejection APIs to be called -- the devices are safe to remove
without notice. So the implementations mainly just simulate their
removal and signal OK to the caller. When the device is then actually
removed, the removal will be swallowed without additional notification.

R=thestig@chromium.org
BUG=257179

Review URL: https://chromiumcodereview.appspot.com/23383009

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@222112 0039d316-1c4b-4281-b951-d872f2087c98

BUG=260278

Review URL: https://chromiumcodereview.appspot.com/23819032

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@222111 0039d316-1c4b-4281-b951-d872f2087c98

This CL makes the client plugin treat a completely transparent mouse cursor as an indication that the host switched to relative mouse mode.

If the browser rejects or cancels the mouse lock for any reason, the plugin sets the cursor to the standard arrow pointer until a new cursor is set by the host.

The webapp has to send the 'allowMouseLock' message to enable this behavior.

BUG=132613

Review URL: https://chromiumcodereview.appspot.com/23484015

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@222110 0039d316-1c4b-4281-b951-d872f2087c98

This will hopefully be the last thing needed to actually make the
archiving of results for webkit_tests work on Android bots. This is
another follow-on to r222092.

TBR=ilevy@chromium.org
BUG=276076

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

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@222109 0039d316-1c4b-4281-b951-d872f2087c98

NOTRY=true
TBR=thestig@chromium.org, henrika@chromium.org
BUG=167299

Review URL: https://chromiumcodereview.appspot.com/23694029

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@222108 0039d316-1c4b-4281-b951-d872f2087c98

This involves exposing the app list model to a BrowserTest, and ensuring
that changes in the model are properly observed by the UI.

BUG=277897,169114
TEST=AppListControllerSearchResultsBrowserTest.UninstallSearchResult

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=221197

Review URL: https://chromiumcodereview.appspot.com/23072036

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@222107 0039d316-1c4b-4281-b951-d872f2087c98

R=sky@chromium.org
http://crbug.com/103304

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

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@222106 0039d316-1c4b-4281-b951-d872f2087c98

Partial re-land of https://codereview.chromium.org/22198004/) -- Always enable FCM on Windows -- Part 1/3.

On top of fixing some of the issues there; only lands the part that enables the GPU blacklist in tests as the former CL is too hard to land all at once.

Also keeping --skip-gpu-data-loading around for now to be able to deal with failures caused in layout_tests by this on their own later (this needs to land ASAP and layout_tests don't need this ASAP).

Another CL will follow to always enable FCM on non-blacklisted Windows machines.

This part re-enables loading the blacklist in tests (and adds a content_browsertest to make sure that the configuration we expect to be testing is indeed the one we are testing -- this uncertainty is basically the only reason the blacklist was explicitly disabled before).

This CL also cleans up compositor_util.cc which was enforcing the blacklist twice.

The original plan was to do this only for Windows as Mac/Linux was causing trouble, but it turns out to be harder to do it only on Windows; so taking care of http://crbug.com/277242 in this CL too after all... 

BUG=233830, 267038, 190942, 277242
TBR=jcivelli, piman 

Originally Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=219132 
Then Reverted: https://src.chromium.org/viewvc/chrome?view=rev&revision=219159

Then re-committed (part 1/3): https://src.chromium.org/viewvc/chrome?view=rev&revision=221114
Reverted in: https://src.chromium.org/viewvc/chrome?view=rev&revision=221145

Review URL: https://chromiumcodereview.appspot.com/23534006

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@222105 0039d316-1c4b-4281-b951-d872f2087c98

FlagsUI assumes that when 
DeviceSettingsService::GetOwnershipStatusAsync is done, it is known
whether the current user is the owner. Since the certificates
are loaded asynchronously it is possible that a SessionManagerOperation
is completed (which triggers GetOwnershipStatusAsync callbacks) before
the certs are loaded. In that case, the owner private key will not be
known even it the current user is the owner, so FlagsUI could be created
with a wrong FlagsDOMHandler.
This is very likely to happen if the about:flags is opened during session restore.

This CL changes GetOwnershipStatusAsync to only report ownership status
(not whether the current user is the owner). 
HasPrivateOwnerKeyAsync is added. This method should be used to check whether
the current user is the owner. It is guaranteed to trigger callback after
the certificates have been loaded.

Also, to avoid showing "This webpage is not available" for the FlagsUI on
session restore (due to cert loading taking too long), change flags UI
to load but not to show anything untli the ownership status is determined.

BUG=280935
TEST=open chrome://flags and reboot. In the chrome://flags page opened 
during session restore (make sure 'Continue where I left off' setting is set),
change enable-nacl flag and reboot. On the next login, there should be no
black screen.
Note: test steps assume usage of the owner account.

Review URL: https://chromiumcodereview.appspot.com/23532034

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@222104 0039d316-1c4b-4281-b951-d872f2087c98

BUG=236290

Review URL: https://chromiumcodereview.appspot.com/23636015

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@222102 0039d316-1c4b-4281-b951-d872f2087c98

Got removed in r218198, reoccured in WebKit memory tests.

NOTRY=true
TBR=thestig@chromium.org, benwells@chromium.org
BUG=214044

Review URL: https://chromiumcodereview.appspot.com/23904006

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@222101 0039d316-1c4b-4281-b951-d872f2087c98

When the target window was closed, new window commands will trigger reconnection to DevTools.
Thus, the original message is misleading.

BUG=none

Review URL: https://chromiumcodereview.appspot.com/23734005

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@222100 0039d316-1c4b-4281-b951-d872f2087c98

BUG=164227
TEST=No

Review URL: https://chromiumcodereview.appspot.com/23623010

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@222099 0039d316-1c4b-4281-b951-d872f2087c98

In the mini_installer test framework, the script quit_chrome.py quits Chrome by sending a WM_CLOSE message to each window of Chrome. Once we send the message to a window, it's possible that the handles to other windows may become invalid (see buildbot error message http://goo.gl/16VmkX). Fix this by catching ERROR_INVALID_WINDOW_HANDLE.

NOTRY=True
BUG=264859
TEST=
1) Uninstall Chrome (if it's installed.) 
2) Build Chrome with Release mode and make sure that mini_installer.exe is created.
3) Go to src\chrome\test\mini_installer 
4) Edit quit_chrome.py. Add line "hwnd = 12345" before the line "win32gui.PostMessage(hwnd, win32con.WM_CLOSE, 0, 0)". Add line "print 'ok'" after the line "raise". Then save.
5) Run "python test_installer.py config\config.config --build-dir=<build-dir> --target=Release" where <build-dir> is the path to main build directory (the parent of the Release directory). It should print "ok" repeatedly.

Review URL: https://chromiumcodereview.appspot.com/23498025

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@222098 0039d316-1c4b-4281-b951-d872f2087c98

This makes fixup strip the "http://" scheme back out when the user didn't type
it, even when it was inserted after "view-source:".

This also fixes highlighting of such input in the resulting matches.

BUG=286451
TEST=Typing "view-source:x" doesn't crash, and highlights correctly in the dropdown
R=beaudoin@chromium.org

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

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@222097 0039d316-1c4b-4281-b951-d872f2087c98

The crash happens if when the HWND is destroyed someone asks if a
child NativeWidgetAura is Active. In particular during this code path
we've gone through ~RootWindow and are in ~Window. When this happens
GetRootWindow() uses Window's implementation, which returns NULL and
we crash.

BUG=264855
TEST=none
R=ben@chromium.org

Review URL: https://chromiumcodereview.appspot.com/23904005

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@222096 0039d316-1c4b-4281-b951-d872f2087c98

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@222095 0039d316-1c4b-4281-b951-d872f2087c98

Review URL: https://chromiumcodereview.appspot.com/23983010

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@222094 0039d316-1c4b-4281-b951-d872f2087c98

R=laforge@chromium.org
BUG=chromium:287879

Review URL: https://chromiumcodereview.appspot.com/23532047

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@222093 0039d316-1c4b-4281-b951-d872f2087c98

TBR=ilevy@chromium.org
BUG=276076

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

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@222092 0039d316-1c4b-4281-b951-d872f2087c98

Revision 222074 did not go through the commit queue. Failing
contet_unittests on win-aura:

  KeySystemsTest.ClearKey_Basic
  KeySystemsTest.ClearKey_Parent
  KeySystemsTest.ExternalClearKey_Parent
  KeySystemsTest.Widevine_Basic
  KeySystemsTest.Widevine_Parent

> Refactor KeySystems code to call a function to populate the info. (re-land r221932)
> 
> This allows KeySystems to call GetContentClient()->AddKeySystems() so we can
> move key system information to chrome/. The new ContentClient API is defined and
> called, but we still rely on key_systems_info.cc.
> 
> BUG=224793
> TEST=Existing content_unittests and content_browsertests pass.
> TBR=jam@chromium.org
> 
> Review URL: https://codereview.chromium.org/23484019

TBR=ddorwin@chromium.org

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

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@222091 0039d316-1c4b-4281-b951-d872f2087c98

<webivew> WebRequest event listeners should survive reparenting of the <webview> within the same embedder WebContents. Currently, event listeners are lost when the <webview> is removed from the DOM. This CL solves this problem.

Note that there is still a problem where custom elements break if the original page that created the element is closed. I have written a test that exercises this problem and I've left the test disabled until we fix the problem.

BUG=281551
Test=WebViewTest.Shim_TestWebRequestListenerSurvivesReparenting

Review URL: https://chromiumcodereview.appspot.com/23514016

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@222090 0039d316-1c4b-4281-b951-d872f2087c98

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@222089 0039d316-1c4b-4281-b951-d872f2087c98

BUG=260005

Review URL: https://chromiumcodereview.appspot.com/23691042

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@222088 0039d316-1c4b-4281-b951-d872f2087c98

BUG=none

Review URL: https://chromiumcodereview.appspot.com/23653029

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@222087 0039d316-1c4b-4281-b951-d872f2087c98

adds and makes use of Renderer.AcceleratedFixedRootBackground UMA histogram.

Records three counts:
1. The total number of main frame scrolls.
2. The total number of main frame scrolls with an accelerated fixed root background.
3. The total number of main frame scrolls with an unaccelerated fixed root background.

R=hartmanng@chromium.org,asvitkine@chromium.org
BUG=None

Review URL: https://chromiumcodereview.appspot.com/23983017

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@222086 0039d316-1c4b-4281-b951-d872f2087c98

R=jar@chromium.org

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

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@222085 0039d316-1c4b-4281-b951-d872f2087c98

To prepare implementing ProgressCallbak, Cancel and stream based copy/move
operation, this CL extracts main file-copying logic into classes.

BUG=279287, 278038, 278036
TEST=Ran content_unittests

Review URL: https://chromiumcodereview.appspot.com/23621026

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@222083 0039d316-1c4b-4281-b951-d872f2087c98

(current URL based hinting and candidate URL upload).
R=jam@chromium.org

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

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@222082 0039d316-1c4b-4281-b951-d872f2087c98

According to
http://test-results.appspot.com/dashboards/flakiness_dashboard.html#group=%40ToT%20Chromium&testType=cc_unittests&tests=LayerTreeHostTestCompositeAndReadbackDuringForcedDraw.RunMultiThread_DirectRenderer_MainThreadPaint,
the test
LayerTreeHostTestCompositeAndReadbackDuringForcedDraw.RunMultiThread_DirectRenderer_MainThreadPaint
has failed 5 times out of 20 attempts on 9/9/2013. Disabling the test and
filing http://crbug.com/287893.

BUG=287893

Review URL: https://chromiumcodereview.appspot.com/23578016

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@222081 0039d316-1c4b-4281-b951-d872f2087c98

Configure Views SSL client certificate selector dialogs to be closed
when interstitial WebUI is displayed (e.g. for SSL warnings prior to
page load).

BUG=221884
R=sky@chromium.org

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

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@222080 0039d316-1c4b-4281-b951-d872f2087c98

BUG=170375

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=221893

R=mpcomplete@chromium.org

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

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@222079 0039d316-1c4b-4281-b951-d872f2087c98