GitLab

In some situations the same JniClient will be used for multiple connections
where ConnectToHost()->DisconnectFromHost()->ConnectToHost() will be called.

In ConnectToHost() we DCHECK !secret_fetcher_ but don't release it in
DisconnectFromHost(), which fails the DCHECK.

This CL solves this problem by resetting |secret_fetcher_| in
DisconnectFromHost(). However, we still need to investigate why JniClient
is being used for multiple connections.

BUG=617471

Review-Url: https://codereview.chromium.org/2046663002
Cr-Commit-Position: refs/heads/master@{#398085}

Revert of In official builds, let CHECK(false) crash instead of calling BreakDebugger. (patchset #2 id:20001 of https://codereview.chromium.org/1982123002/ )

Reason for revert:
Unfortunately crrev.com/1982123002 causes loss of
crash reports on Android arm64 (and supposedly also CrOS).
This is because __builtin_trap() raises a SIGILL on x86 and
arm but SIGTRAP on arm64. Breakpad does not handle SIGTRAP (yet).
Temporarily reverting this CL until SIGTRAP support for breakpad lands.

BUG=599867,614865

Original issue's description:
> In official builds, let CHECK(false) crash instead of calling BreakDebugger.
>
> This should save some binary size and make things a bit faster, without ill
> effects.
>
> See bug comment 15, and brettw's and my comments on
> "[blink-dev] Update of wtf/Assertions.h, and ASSERT macros deprecation"
>
> BUG=599867
>
> Committed: https://crrev.com/481a8ec8b24df24795c63fd4ec26f3670d516db8
> Cr-Commit-Position: refs/heads/master@{#394035}

TBR=danakj@chromium.org,thakis@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=599867

Review-Url: https://codereview.chromium.org/2046593002
Cr-Commit-Position: refs/heads/master@{#398084}

Since AudioCodecBridge::ConfigureAndStart creates AudioTrack
instance with config parameters, we need to initialize the
output parameters with the same values before we get
OnOutputFormatChanged().

Without this step the some changes between config and actual
parameters will be undetected, for instance before this change
(1) config_num_channels = 2, output_num_channels = 2
      old output value was 0, unnecessary AudioTrack recreation
(2) config_num_channels = 1, output_num_channels = 2
      old output value was 2, no change detected here but
      AudioTrack was created with num_channels = 1

BUG=none

Review-Url: https://codereview.chromium.org/2042563002
Cr-Commit-Position: refs/heads/master@{#398083}

MessageLoop::PostTask/PostDelayedTask/DeleteSoon/ReleaseSoon
are deprecated. This CL makes the following replacements to
remove some uses of these methods:

"MessageLoop(ForUI|ForIO)::current()->PostTask" ->
  "ThreadTaskRunnerHandle::Get()->PostTask"
"MessageLoop(ForUI|ForIO)::current()->PostDelayedTask" ->
  "ThreadTaskRunnerHandle::Get()->PostDelayedTask"
"MessageLoop(ForUI|ForIO)::current()->DeleteSoon" ->
  "ThreadTaskRunnerHandle::Get()->DeleteSoon"
"MessageLoop(ForUI|ForIO)::current()->ReleaseSoon" ->
  "ThreadTaskRunnerHandle::Get()->ReleaseSoon"

In files where these replacements are made, it adds these includes:
  #include "base/location.h"
  #include "base/single_thread_task_runner.h"
  #include "base/threading/thread_task_runner_handle.h"

And removes this include if it is no longer required:
  #include "base/message_loop/message_loop.h"

Why ThreadTaskRunnerHandle::Get() instead of
MessageLoop::current()->task_runner()?
 - The two are equivalent on threads that run a MessageLoop.
 - MessageLoop::current() doesn't work in base/task_scheduler
   because the scheduler's thread don't run MessageLoops.
   This CL will therefore facilitate the migration of browser
   threads to base/task_scheduler.

Steps to generate this patch:
1. Run message_loop_cleanup.py (see code on the bug).
2. Run tools/sort-headers.py on modified files.
3. Run git cl format.

BUG=616447
R=maxbogue@chromium.org

Review-Url: https://codereview.chromium.org/2033933002
Cr-Commit-Position: refs/heads/master@{#398082}

This was an error in the refactoring at https://codereview.chromium.org/1323313004.

BUG=615056

Review-Url: https://codereview.chromium.org/2042623002
Cr-Commit-Position: refs/heads/master@{#398081}

There seems to be nothing called InspectorFrontend. Removed unused
forward declarations for it and changed comments to say "frontend"
instead.

R=pfeldman@chromium.org,dgozman@chromium.org

Review-Url: https://codereview.chromium.org/2046433002
Cr-Commit-Position: refs/heads/master@{#398080}

FontDataCache's key data type was a full FontPlatformData object, not a
pointer to one The value type of that cache is a SimpleFontData object,
which in itself stores a FontPlatformData object type.

If we want to manage memory related to font blobs (OpenType tables, web
font file buffers) we need to come to a situation where the lifecycle of
FontPlatformData objects is absolutely clear.

Previously, adding to the FontDataCache meant one copy of
FontPlatformData for the cache key, and one for the value as an owned
member of SimpleFontData.

In this situation, it is much harder to keep track of where we keep
FontPlatformData objects.

FontPlatformData objects keep a RefPtr<HarfBuzzFace>, which in turn
keeps hb_font objects, which keep references to OpenType tables copied
from Skia. If we cannot destroy FontPlatformData objects after use, we
cannot free the corresponding copied OpenType tables - so over the
lifetime of the renderer we're leaking OpenType table data for stale
FontPlatformData objects.

This is a first step towards fixing this situation and gaining better
control over the lifecylce of FontPlatformData objects.

BUG=617568
R=eae,tzik,bashi

Review-Url: https://codereview.chromium.org/2031363002
Cr-Commit-Position: refs/heads/master@{#398079}

Separate clip rect and visible rect calculation so visible rect logic
would be easier to follow.

R=ajuma
BUG=594675
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

Review-Url: https://codereview.chromium.org/2008283003
Cr-Commit-Position: refs/heads/master@{#398078}

Adds a test to make sure sequential navs are handled correctly, and also add histogram checks to all tab helper tests.

BUG=589526

Review-Url: https://codereview.chromium.org/2040573002
Cr-Commit-Position: refs/heads/master@{#398077}

Context:
This bot has not been running for about 2 months now. When it was running it did not generate any useful alerts.
These files were originally added in https://codereview.chromium.org/1410353007/

# Failing with missing LGTM from OWNER for chrome/ct_top1k.isolate even though M-A LGTM'ed.
TBR=maruel

BUG=skia:4503

Review-Url: https://codereview.chromium.org/2039973002
Cr-Commit-Position: refs/heads/master@{#398076}

MediaStreamDispatcher::OnDeviceStopped() may delete the same element
twice from |label_stream_map_| and causes the crash.

BUG=616884

Review-Url: https://codereview.chromium.org/2035993002
Cr-Commit-Position: refs/heads/master@{#398075}

Account now switches when focus changes, not just updated wallpaper.

BUG=614926

Review-Url: https://codereview.chromium.org/2035753003
Cr-Commit-Position: refs/heads/master@{#398074}

The previous CL was built around a test case I had made myself (there was no real life example). I found one and realized the type should be "text" and not "input".

Related CL: https://codereview.chromium.org/2025063002/

BUG=616174
TEST=AutofillFieldTest

Review-Url: https://codereview.chromium.org/2041863003
Cr-Commit-Position: refs/heads/master@{#398073}

The extension TabHelper can have an associated extension if the
WebContents holds a hosted app. Watch for that extension being
unloaded and reset the reference to the extension if it is so that
we don't UAF it.

BUG=616057
BUG=616113

Review-Url: https://codereview.chromium.org/2037873002
Cr-Commit-Position: refs/heads/master@{#398072}

The name content::VideoFrameProvider was easy to cause confusion with
cc:VideoFrameProvider. Furthermore, the methods provided in the
content::VideoFrameProvider are not specific to Video, which makes the
name somewhat unsuitable.

List of changes:
* Moved the typedef content::VideoFrameProvider::RepaintCB out to a new
  file and renamed it to VideoFrameCallback.
* Renamed interface VideoFrameProvider to PausableStream
* Renamed method Play() to Resume()

BUG=526835

Review-Url: https://codereview.chromium.org/2005053006
Cr-Commit-Position: refs/heads/master@{#398071}

This is just a mechanical rename and reformat. The rename is good because:

 1) WebUI::CallJavascriptFunctionUnsafe is indeed unsafe and the caller
    is responsible for knowing when it is safe to call.

 2) WebUIMessageHandler::CallJavascriptFunction is the new preferred way.

 3) The change makes the above two points clear to coders not to use
    WebUI directly unless they know what they are doing.

In the future, WebUI::CallJavascriptFunctionUnsafe may become a private
member with a few friend classes.

See design doc for more details:
https://docs.google.com/a/chromium.org/document/d/1z1diKvwgMmn4YFzlW1kss0yHmo8yy68TN_FUhUzRz7Q/edit?usp=sharing

BUG=602523

Review-Url: https://codereview.chromium.org/1995113002
Cr-Commit-Position: refs/heads/master@{#398070}

BitmapUploader is needed only for chrome when it uses software rendering. So
instead of always creating a BitmapUploader (which creates an extra surface for
the window) for every widget, create it only when needed.

BUG=none

Review-Url: https://codereview.chromium.org/2040453002
Cr-Commit-Position: refs/heads/master@{#398069}

Reject calcs with both lengths and percentages in radial-gradient,
while for ellipse both length and percentage are allowed, they are
not allowed at the same time [1].

[1] https://drafts.csswg.org/css-images-3/#radial-gradients

Review-Url: https://codereview.chromium.org/1935173002
Cr-Commit-Position: refs/heads/master@{#398068}

In https://codereview.chromium.org/2025393003/ I moved the visualViewport object
from document onto window but forgot to move the event to fire on the window
instead.

BUG=595826

Review-Url: https://codereview.chromium.org/2034313002
Cr-Commit-Position: refs/heads/master@{#398067}

BUG=none
TEST=covered by tests
R=jamescook@chromium.org

Review-Url: https://codereview.chromium.org/2033843003
Cr-Commit-Position: refs/heads/master@{#398066}

Revert of Suppress -Wnonportable-include-path on clang tot bots (patchset #2 id:20001 of https://codereview.chromium.org/2040533003/ )

Reason for revert:
The Clang warning was removed again in r271761.

Original issue's description:
> Suppress -Wnonportable-include-path on clang tot bots
>
> BUG=617318
> R=hans@chromium.org
>
> Committed: https://chromium.googlesource.com/chromium/src/+/2bc751024e4ddf3f50594abdbf3c54b77df84562

TBR=thakis@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=617318

Review-Url: https://codereview.chromium.org/2043813002
Cr-Commit-Position: refs/heads/master@{#398065}

MessageLoop::PostTask/PostDelayedTask/DeleteSoon/ReleaseSoon
are deprecated. This CL makes the following replacements to
remove some uses of these methods:

"MessageLoop(ForUI|ForIO)::current()->PostTask" ->
  "ThreadTaskRunnerHandle::Get()->PostTask"
"MessageLoop(ForUI|ForIO)::current()->PostDelayedTask" ->
  "ThreadTaskRunnerHandle::Get()->PostDelayedTask"
"MessageLoop(ForUI|ForIO)::current()->DeleteSoon" ->
  "ThreadTaskRunnerHandle::Get()->DeleteSoon"
"MessageLoop(ForUI|ForIO)::current()->ReleaseSoon" ->
  "ThreadTaskRunnerHandle::Get()->ReleaseSoon"

In files where these replacements are made, it adds these includes:
  #include "base/location.h"
  #include "base/single_thread_task_runner.h"
  #include "base/threading/thread_task_runner_handle.h"

And removes this include if it is no longer required:
  #include "base/message_loop/message_loop.h"

Why ThreadTaskRunnerHandle::Get() instead of
MessageLoop::current()->task_runner()?
 - The two are equivalent on threads that run a MessageLoop.
 - MessageLoop::current() doesn't work in base/task_scheduler
   because the scheduler's thread don't run MessageLoops.
   This CL will therefore facilitate the migration of browser
   threads to base/task_scheduler.

Steps to generate this patch:
1. Run message_loop_cleanup.py (see code on the bug).
2. Run tools/sort-headers.py on modified files.
3. Run git cl format.

BUG=616447
R=danakj@chromium.org
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

Review-Url: https://codereview.chromium.org/2034913002
Cr-Commit-Position: refs/heads/master@{#398064}

Revert of Specify direct dependency of //components/crash on kasko_features.h (patchset #1 id:1 of https://codereview.chromium.org/2038473002/ )

Reason for revert:
It's breaking the official win-asan builder (https://uberchromegw.corp.google.com/i/official.desktop/builders/win-asan/builds/268)

Original issue's description:
> Specify direct dependency of //components/crash on kasko_features.h
>
> //components/crash/content/app has a public dependency on the generated
> header kasko_features.h. However, the GYP and GN files specify this
> dependency only transitively via a dependency on //third_party/kasko
> (which //components/crash/content/app does not actually depend on). This
> CL changes the dependency to be directly on
> //third_party/kasko:kasko_features as a speculative fix for the build
> failures listed in crbug.com/611319. Note that in any case this change
> is correct (whether it ends up resolving the flaky build failures or no).
>
> BUG=611319
> TBR=pmonette
>
> Committed: https://crrev.com/d507af25f7281161a3eb0d44a0deef057e46c8dc
> Cr-Commit-Position: refs/heads/master@{#397390}

TBR=mark@chromium.org,pmonette@chromium.org,blundell@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=611319

Review-Url: https://codereview.chromium.org/2047473002
Cr-Commit-Position: refs/heads/master@{#398063}

MessageLoop::PostTask/PostDelayedTask/DeleteSoon/ReleaseSoon
are deprecated. This CL makes the following replacements to
remove some uses of these methods:

"MessageLoop(ForUI|ForIO)::current()->PostTask" ->
  "ThreadTaskRunnerHandle::Get()->PostTask"
"MessageLoop(ForUI|ForIO)::current()->PostDelayedTask" ->
  "ThreadTaskRunnerHandle::Get()->PostDelayedTask"
"MessageLoop(ForUI|ForIO)::current()->DeleteSoon" ->
  "ThreadTaskRunnerHandle::Get()->DeleteSoon"
"MessageLoop(ForUI|ForIO)::current()->ReleaseSoon" ->
  "ThreadTaskRunnerHandle::Get()->ReleaseSoon"

In files where these replacements are made, it adds these includes:
  #include "base/location.h"
  #include "base/single_thread_task_runner.h"
  #include "base/threading/thread_task_runner_handle.h"

And removes this include if it is no longer required:
  #include "base/message_loop/message_loop.h"

Why ThreadTaskRunnerHandle::Get() instead of
MessageLoop::current()->task_runner()?
 - The two are equivalent on threads that run a MessageLoop.
 - MessageLoop::current() doesn't work in base/task_scheduler
   because the scheduler's thread don't run MessageLoops.
   This CL will therefore facilitate the migration of browser
   threads to base/task_scheduler.

Steps to generate this patch:
1. Run message_loop_cleanup.py (see code on the bug).
2. Run tools/sort-headers.py on modified files.
3. Run git cl format.

BUG=616447
R=garykac@chromium.org

Review-Url: https://codereview.chromium.org/2031083002
Cr-Commit-Position: refs/heads/master@{#398062}

We are looking into a more consistent audio playback on mobile and want
to see whether implementing Safari iOS behaviour in Chrome Android would
break websites.

BUG=616807

Review-Url: https://codereview.chromium.org/2031393003
Cr-Commit-Position: refs/heads/master@{#398061}

values and the overall renderer memory stats.

BUG=617117
CQ_EXTRA_TRYBOTS=tryserver.chromium.perf:android_s5_perf_cq;tryserver.chromium.perf:mac_retina_perf_cq

Review-Url: https://codereview.chromium.org/2030343002
Cr-Commit-Position: refs/heads/master@{#398060}

When retrieving getScaledFont() from HarfBuzzFace we were creating a
SimpleFontData and assigning it to the HarfBuzzFontData object that is
kept as the user data pointer for HarfBuzz callbacks. This introduces a
reference counting cycle since SimpleFontData owns the FontPlatformData
it was created from, and harfBuzzFace() is retrieved from
FontPlatformData itself.

Since getScaledFont() is called on a HarfBuzzFace instance that is
retrieved from FontPlatformData and only used for one shaping iteration,
reducing the link to SimpleFontData to a non owning pointer should be
acceptable.

BUG=617637
R=eae,tzik,kojii

Review-Url: https://codereview.chromium.org/2039263002
Cr-Commit-Position: refs/heads/master@{#398059}

The shippingAddress attribute was already added by this issue[1] but current
implementation isn't supporting the attribute yet. So, we should provide the
attribute in PaymentResponse.

[1] https://github.com/w3c/browser-payment-api/pull/139

BUG=617194

Review-Url: https://codereview.chromium.org/2038333002
Cr-Commit-Position: refs/heads/master@{#398058}

Chromoting no longer relies on the sas.dll so we can clean up some of the
build files and remove these variables.

BUG=

Review-Url: https://codereview.chromium.org/2030423002
Cr-Commit-Position: refs/heads/master@{#398057}

https://chromium.googlesource.com/skia.git/+log/38d1adf1f7f4..09f5cd44ae30

$ git log 38d1adf1f..09f5cd44a --date=short --no-merges --format='%ad %ae %s'
2016-06-06 scroggo Prefix png functions
2016-06-06 jvanverth Use intptr_t for onTouch argument.
2016-06-06 scroggo Update pnglibconf.h
2016-06-06 msarett Use SK_TEST_QCMS to mark qcms test code

CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
TBR=mtklein@google.com

Review-Url: https://codereview.chromium.org/2043643003
Cr-Commit-Position: refs/heads/master@{#398056}

MessageLoop::PostTask/PostDelayedTask/DeleteSoon/ReleaseSoon
are deprecated. This CL makes the following replacements to
remove some uses of these methods:

"MessageLoop(ForUI|ForIO)::current()->PostTask" ->
  "ThreadTaskRunnerHandle::Get()->PostTask"
"MessageLoop(ForUI|ForIO)::current()->PostDelayedTask" ->
  "ThreadTaskRunnerHandle::Get()->PostDelayedTask"
"MessageLoop(ForUI|ForIO)::current()->DeleteSoon" ->
  "ThreadTaskRunnerHandle::Get()->DeleteSoon"
"MessageLoop(ForUI|ForIO)::current()->ReleaseSoon" ->
  "ThreadTaskRunnerHandle::Get()->ReleaseSoon"

In files where these replacements are made, it adds these includes:
  #include "base/location.h"
  #include "base/single_thread_task_runner.h"
  #include "base/threading/thread_task_runner_handle.h"

And removes this include if it is no longer required:
  #include "base/message_loop/message_loop.h"

Why ThreadTaskRunnerHandle::Get() instead of
MessageLoop::current()->task_runner()?
 - The two are equivalent on threads that run a MessageLoop.
 - MessageLoop::current() doesn't work in base/task_scheduler
   because the scheduler's thread don't run MessageLoops.
   This CL will therefore facilitate the migration of browser
   threads to base/task_scheduler.

Steps to generate this patch:
1. Run message_loop_cleanup.py (see this CL's comments).
2. Run tools/sort-headers.py on modified files.
3. Run git cl format.

BUG=616447
R=boliu@chromium.org

Review-Url: https://codereview.chromium.org/2030193003
Cr-Commit-Position: refs/heads/master@{#398055}

Review-Url: https://codereview.chromium.org/2039043002
Cr-Commit-Position: refs/heads/master@{#398054}

R=thakis@chromium.org
BUG=605732

Review-Url: https://codereview.chromium.org/2000413002
Cr-Commit-Position: refs/heads/master@{#398053}

https://pdfium.googlesource.com/pdfium.git/+log/c324646..f7e108b

BUG=427616,616253,616838,613623
TBR=dsinclair@chromium.org

TEST=bots

Review-Url: https://codereview.chromium.org/2046623002
Cr-Commit-Position: refs/heads/master@{#398052}

https://chromium.googlesource.com/external/github.com/catapult-project/catapult.git/+log/0c6dbf87bab3..8f31b02e7cdf

$ git log 0c6dbf87b..8f31b02e7 --date=short --no-merges --format='%ad %ae %s'

BUG=552376,617174

TBR=catapult-sheriff@chromium.org

Review-Url: https://codereview.chromium.org/2039933002
Cr-Commit-Position: refs/heads/master@{#398051}

BUG=615825

Review-Url: https://codereview.chromium.org/2036323002
Cr-Commit-Position: refs/heads/master@{#398050}

According to the section 3 and section 5 in
https://tools.ietf.org/html/draft-west-cookie-priority-
00#section-3, the old cookie monster implementation doesn't
maintain priority quotas correctly.

This CL makes sure there will always be at least 30 low
priority cookies, 50 mid priority and 70 high priority
cookies if there had been enough of them before  the eviction.
Please note, secure cookies are more important than non-secure
per https://tools.ietf.org/html/draft-west-leave-secure-cookies-alone.

A small example: if there are 70 cookies:
37 non-secure low priority and 33 secure low priority
cookies, 37 non-secure cookies are deleted during the first
round and other 3 secure low priority cookies are deleted
during the following round preserving 30 low priority
cookies according to the quota of those specific cookies.
For a bigger example that fully complies with the
implementation, check the unittests.

Before the fix, the unittests were just adjusted to the
behavior of cookies eviction.

For example, if we take the following unittest:
Round 1 => 10L; round 2 => 11M, 10L; round 3 => none.
TestPriorityCookieCase(cm.get(), "11HN 10MN 20LN 110MN 20LN
10HN", 20U,109U, 21U, 150U, 0U);
The problem here was that there were only 40 low priority
cookies, but the quota was not preserved for those cookies.
First, 10 low priority cookies were deleted and then more 10
low priority cookies were deleted leaving only 20 of them,
which was less than the quota (30 low priority cookies).
It happened because the eviction algorithm didn't know how
many cookies of a specific priority were deleted and
it had always started to delete all the cookies from the
beginning of the container removing even those cookies
that shouldn't have been deleted.

After we land this CL, we can have cookies in any order and
high priority cookies will be eventually deleted in order
to avoid excess of high priority cookies by some
applications within the same domain. Thus, after the
eviction algorithm runs, we should have at least 30 low, 50
mid and 70 high priority cookies if we had sufficient
amount of them in the beginning.

BUG=609550

Review-Url: https://codereview.chromium.org/1976073002
Cr-Commit-Position: refs/heads/master@{#398049}

Its weird that the rootScroller property on document takes an Element but the
RootScroller object is really a manager class. Rename it to make this more clear
and prevent confusion.

BUG=505516

Review-Url: https://codereview.chromium.org/2040693002
Cr-Commit-Position: refs/heads/master@{#398048}

MessageLoop::PostTask/PostDelayedTask/DeleteSoon/ReleaseSoon
are deprecated. This CL makes the following replacements to
remove some uses of these methods:

"MessageLoop(ForUI|ForIO)::current()->PostTask" ->
  "ThreadTaskRunnerHandle::Get()->PostTask"
"MessageLoop(ForUI|ForIO)::current()->PostDelayedTask" ->
  "ThreadTaskRunnerHandle::Get()->PostDelayedTask"
"MessageLoop(ForUI|ForIO)::current()->DeleteSoon" ->
  "ThreadTaskRunnerHandle::Get()->DeleteSoon"
"MessageLoop(ForUI|ForIO)::current()->ReleaseSoon" ->
  "ThreadTaskRunnerHandle::Get()->ReleaseSoon"

In files where these replacements are made, it adds these includes:
  #include "base/location.h"
  #include "base/single_thread_task_runner.h"
  #include "base/threading/thread_task_runner_handle.h"

And removes this include if it is no longer required:
  #include "base/message_loop/message_loop.h"

Why ThreadTaskRunnerHandle::Get() instead of
MessageLoop::current()->task_runner()?
 - The two are equivalent on threads that run a MessageLoop.
 - MessageLoop::current() doesn't work in base/task_scheduler
   because the scheduler's thread don't run MessageLoops.
   This CL will therefore facilitate the migration of browser
   threads to base/task_scheduler.

Steps to generate this patch:
1. Run message_loop_cleanup.py (see code on the bug).
2. Run tools/sort-headers.py on modified files.
3. Run git cl format.

BUG=616447
R=chcunningham@chromium.org

Review-Url: https://codereview.chromium.org/2029403004
Cr-Commit-Position: refs/heads/master@{#398047}

BUG=616657
R=pfeldman@chromium.org,thakis@chromium.org

Review-Url: https://codereview.chromium.org/2038593002
Cr-Commit-Position: refs/heads/master@{#398046}