GitLab

> use accessTopLayer instead of (DEPRECATED) getTopDevice
> 
> NOTRY=True
> 
> the win_chromium_rel failure must be a flake, since my CL only edits mac-only files.
> 
> the mac gpu failure is unrelated to this CL
> 
> Review URL: https://codereview.chromium.org/248113005

TBR=reed@google.com

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

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

The tip is to suggest auth flows are initiated from app UI explaining
why. Without this, if a signed out user launches an app that immediately
initiates an interactive auth session, the first thing the user sees is
a chrome signin screen.

BUG=372279

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

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

There's some logic in ServiceRuntime to support a future implementation for
CloseManifestEntry, but since we don't take any useful action, it's much
simpler to always return true. This makes ServiceRuntime even smaller.

This also removes an unused struct in ServiceRuntime.

BUG=239656

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

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

BUG=NONE

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

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

This is important to make sure apps handle this, particularly when we
remove the sign in requirements.

BUG=372279

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

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

BUG=361266

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

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

We currently have tests only for the full IME layout. Expand the IME test framework to test the Compact layout as well.

BUG=372539

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

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

BUG=339762

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

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

Also try to touch (potentially corrupt) arrays, but do not insist on specific
values being present.

I also tidy up the JS a bit, getting rid of some underscores and double-quotes
that crept in despite what the style guide says.

R=viettrungluu@chromium.org

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

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

The ViewMsg_SetBackground message currently passes an SkBitmap that
signals if the RenderView should have an opaque background or not. We
can use a bool instead to convey this data.

Rename the ViewMsg_SetBackground to ViewMsg_SetBackgroundOpaque as well
as the Set/GetBackground methods on the various RenderWidget/View
classes.

RenderWidget itself no longer needs to know about the background opaque
changes.

R=kenrb, piman
BUG=362164

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

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

BUG=none
R=sbc@chromium.org

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

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

* Be tolerant of truncated files. These happen in practice if the fuzzer
runs out of disk space.

* Clear the decoder's input buffer if decoding fails.

* Relax third-stage decoder checks, as there are valid cases where the
second-stage encoder produces an output which the decoder will refuse.

BUG=353237

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

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

[Hotword] Add new base URLs for the additional languages so it works on their respective local search urls.

The function has been tested manually inside Chrome since it will not work as part of the larger system until the extension and some server side pieces are in place.

BUG=345806

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

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

BUG=371469

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

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

GetPNaClResourceInfo() currently performs a 1 megabyte allocation. Though any
memory allocation can fail, this one is more likely due to its size.

This change mitigates this problem in two ways. If memory allocation fails, we
report an error and return early instead of using memory.

Additionally, this change checks the size of the file before performing a
memory allocation. This should lead to smaller allocations and more successful
plugin loads.

BUG=370965

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

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

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

BUG=370925
TEST=ash_unittests and visual (using wifi advanced dialog which is the biggest known dialog)

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

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

With this patch, pixels appear on screen and tab capture works.

Add a OnNativeSurfaceBuffersSwapped mechanism to display
an IOSurface to an NSView. This is wired up to the existing
CompositingIOSurfaceMac. In a future refactoring, something
much more light-weight than CompositingIOSurfaceMac will
be used (CompositingIOSurfaceMac has capture code, etc, in
it).

Add a DelegatedFrameHost to RenderWidgetHostViewMac, and
hookup the DelegatedFrameHostClient implementation. Create
the DelegatedFrameHost when a delegated frame is received, and
use its existence to determine which mode is active.

BUG=314190

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

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

Change log for this release:
- Remove searchvox uncompiled js files.
- Allow aria live regions to be announced when observed on a background tab.
- Correctly speak live regions that have opacity 0 when shown but
  subsequently fade in.
- Announce changes to controls trigged on key up, not just on key down.
- Remove key echo work around so Google U.S. English (from the web store),
  can speak characters again.
- Don't read the entire contents of a dialog when first focused.


BUG=372552
TBR=dtseng@chromium.org

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

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

BUG=372349, 371626, 371204

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

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

BUG=372630
R=raymes@chromium.org

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

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

In OpenVPN, it is up to the client to decide whether or not to
create a default route through the OpenVPN server.  Even when the
server supplies a gateway address, it isn't always clear if the
intent is for the client to set a default route through this
gateway.

By default, ChromeOS creates a default route to the gateway.
This CL adds an ONC configuration option to allow ONC to override
this default behavior, thus providing the means for a "split
tunnel" configuration in situations where the route configuration
provided by the VPN server is amenable to this.  Supplying this
option does not override any explicit routes pushed by the server.

BUG=370460
R=pneubeck@chromium.org

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

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

Verifies that FindCursorPosition works with GetGlyphBounds values.

Prompted by a question reviewing Cem's WIP RenderTextHarfBuzz:
https://codereview.chromium.org/152473008/diff/100001/ui/gfx/render_text_harfbuzz.cc#newcode787
I thought RenderTextWin::GetRunContainingXCoord needed visual run order.
Logical run order is fine as-is, because it checks the range of x bounds.
(RenderTextHarfBuzz should probably do the same thing to be safe/correct)

BUG=NONE
TEST=NONE
R=asvitkine@chromium.org

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

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

Part 1: https://codereview.chromium.org/282533002/


BUG=n/a
TEST=content_unittests --gtest_filter=ServiceWorkerDatabaseTest.*

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

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

In password_manager_unittests and password_form_manager_unittests.

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

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

BUG=351245

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

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

This adds the implementation for the second-layer sandbox, with tests, but
it does not wire it up for use in Chrome.

Design document:
https://docs.google.com/a/chromium.org/document/d/108sr6gBxqdrnzVPsb_4_JbDyW1V4-DRQUC4R8YvM40M/edit

BUG=367863
TEST=Covered by unit tests, manually verified on 10.6.8, 10.7.5, 10.8.5, and 10.9.2.

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

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

BUG=367677

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

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

This patch checks that the length passed to cfread() is non
negative. The individual read methods on cfread() check for failure
while reading a negative value, but the actual failure is a malformed
patch.

R=mark@chromium.org
BUG=chromium:372525
TEST=Manually run a local bad patch and check it fails with the new message.

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

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

BUG=

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

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

ViewEventTestBase (which this subclasses) installs a views_delegate,
so we don't need it here too.

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

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

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

If there is an extra white space in the param, the param will not be used in the auto generated jni file

BUG=372459
R=trchen@chromium.org

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

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

Removes the call to LayerTreeHost::CompositeAndReadback and just fail
immediately. This method should be replaced with an async readback
in order to get pixels again.

R=powei
BUG=252046

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

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

R=thestig@chromium.org

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

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

Next, I need to write tests.

R=yzshen@chromium.org

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

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

BUG=367831
TEST=components_unittests --gtest_filter=BookmarkExpandedStateTrackerTest.*
R=sky@chromium.org,blundell@chromium.org
NOTRY=true

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

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

This test does not seem to need any ResourceBundle initialization and
does not seem to depend on any global state or extra setup, so it should
be fine to move it straightforward into gfx_unittests without any other
modifications.

BUG=331829
TEST=ui_unittests, gfx_unittests
TBR=ben@chromium.org, danakj@chromium.org
NOTRY=true

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

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

Don't allow .h files in mojo/embedder to include files from mojo/system
(except for system_impl_export.h).

R=sky@chromium.org

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

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

This was factored out in r260482, but somehow I forgot to delete the old
definitions.

R=sky@chromium.org

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

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

R=sky@chromium.org

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

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

Adds logic to have the model-thread NonBlockingDataTypeProcessor send
a message to the sync-thread SyncCore when it receives notifcation from
the ui-thread NonBlockingDataTypeController that it should stop syncing.
This message will allow the sync thread to stop requeting updates and
commits on behalf of the now-disabled type.

Fixes the handling of a race in the NonBlockingDataTypeProcessor.  The
race is as follows:
1. NBDTP receives a request to enable sync from the UI thread, and sends
   a connection request to the sync thread via SyncCoreProxy.
2. NBDTP receives a request to disable sync from the UI thread.  It
   updates its internal state accordingly.
3. NBDTP receives the connection OK response from the sync thread,
   which was genrated in response to its request in step 1.

Previously, the processor would wrongly set itself to the enable state
in step 3.  The fix is to use a new WeakPtrFactory and invalidate the
pointers it has issued in step 2 in order to prevent the response seen
in step 3 from being run.

Adds some more tests for this scenario and more.  The test framework had
to be made a bit more complicated in order to handle these tests, but
I think the extra complexity is worth it.  I don't know of any other
way to reliably defend against these race cases.

BUG=351005

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

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