Switch to LayoutThemeMobile when emulating mobile device in DevTools.

Switch to LayoutThemeMobile when emulating mobile device in DevTools.

This covers subtle differences between rendering on mobile vs desktop platforms (see bugs).

LayoutTheme decides whether to use mobile theme based on mobileLayoutThemeEnabled.
To accomplish this, NEW_THEME build flag was removed. Instead, non-null Theme* is passed to
LayoutTheme as equivalent to USE(NEW_THEME), and LayoutTheme decides which code path to use.
Only LayoutThemeMac passes non-null Theme* since NEW_THEME was only implemented on mac.

Introduced ComputedStyle::invalidateInitialStyle to recalculate static values which may be
affected by LayoutTheme change.

BUG=585459, 543356, 586408
Committed: https://crrev.com/638717eea162abcacb1f797faeafa3df6f85456a
Cr-Commit-Position: refs/heads/master@{#377198}

[dgozman, 2016-02-10 02:14:09]

The CQ bit was checked by dgozman@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-02-10 02:15:35]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1690493002/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1690493002/1

[commit-bot: I haz the power, 2016-02-10 02:35:43]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-02-10 02:35:43]

Dry run: Try jobs failed on following builders:
  android_arm64_dbg_recipe on tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_arm6...)
  linux_android_rel_ng on tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)
  mac_chromium_compile_dbg_ng on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)
  mac_chromium_gn_rel on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_gn_r...)

[dgozman, 2016-02-10 03:00:24]

The CQ bit was checked by dgozman@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-02-10 03:05:24]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1690493002/40001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1690493002/40001

[commit-bot: I haz the power, 2016-02-10 03:22:37]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-02-10 03:22:38]

Dry run: Try jobs failed on following builders:
  mac_chromium_gn_rel on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_gn_r...)
  mac_chromium_rel_ng on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[dgozman, 2016-02-10 17:51:03]

The CQ bit was checked by dgozman@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-02-10 17:51:56]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1690493002/60001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1690493002/60001

[commit-bot: I haz the power, 2016-02-10 18:36:48]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-02-10 18:36:48]

Dry run: Try jobs failed on following builders:
  mac_chromium_rel_ng on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[dgozman, 2016-02-11 01:59:37]

The CQ bit was checked by dgozman@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-02-11 02:04:26]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1690493002/80001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1690493002/80001

[commit-bot: I haz the power, 2016-02-11 03:46:19]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-02-11 03:46:20]

Dry run: This issue passed the CQ dry run.

[dgozman, 2016-02-11 18:52:07]

Description was changed from

==========
Switch to LayoutThemeMobile when emulating device.

This covers subtle differences between rendering on mobile vs desktop platforms.
LayoutTheme decides whether to use mobile theme based on
mobileLayoutThemeEnabled.
Introduced invalidation of initial computed style to take new layout theme into
account.

BUG=585459,543356
==========

to

==========
Switch to LayoutThemeMobile when emulating mobile device in DevTools.

This covers subtle differences between rendering on mobile vs desktop platforms.
LayoutTheme decides whether to use mobile theme based on
mobileLayoutThemeEnabled.
Introduced invalidation of initial computed style to take new layout theme into
account.

BUG=585459,543356
==========

[dgozman, 2016-02-11 18:53:43]

dgozman@chromium.org changed reviewers:
+ pdr@chromium.org

[dgozman, 2016-02-11 18:53:44]

Hi Philip,

Could you please take a look? You are both an OWNER of core/layout and
core/paint, so I am sending this patch to you. Please route to someone else if
needed.

Most of the patch is about making this code to build on all platforms.

Thanks,
Dmitry

https://codereview.chromium.org/1690493002/diff/80001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/layout/LayoutTheme.cpp (right):

https://codereview.chromium.org/1690493002/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/layout/LayoutTheme.cpp:73:
DEFINE_STATIC_REF(LayoutTheme, layoutThemeMobile,
(LayoutThemeMobile::create()));
This is the meaningful part of the patch.

https://codereview.chromium.org/1690493002/diff/80001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/style/ComputedStyle.cpp (right):

https://codereview.chromium.org/1690493002/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/style/ComputedStyle.cpp:86: void
ComputedStyle::clearInitialStyle()
I need some kind of invalidation mechanism which rebuilds initial style created
with DEFINE_STATIC_GLOBAL. I tried to make it least intrusive, but any ideas are
welcome.

https://codereview.chromium.org/1690493002/diff/80001/third_party/WebKit/Sour...
File third_party/WebKit/Source/web/DevToolsEmulator.cpp (right):

https://codereview.chromium.org/1690493002/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/web/DevToolsEmulator.cpp:261:
RuntimeEnabledFeatures::setMobileLayoutThemeEnabled(true);
I was thinking about testing this, but didn't come up with anything good. I
wouldn't like to test differences in LayoutThemes in devtools emulation test.
And checking that enabling emulation toggles this switch sounds like a test for
the sake of nothing.

[pdr., 2016-02-12 06:36:13]

pdr@chromium.org changed reviewers:
+ thakis@chromium.org

[pdr., 2016-02-12 06:36:14]

https://codereview.chromium.org/1690493002/diff/80001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/BUILD.gn (right):

https://codereview.chromium.org/1690493002/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/BUILD.gn:241: sources -= [
"layout/LayoutThemeFontProviderDefault.cpp" ]
I'm a little out of my depth with these build changes. My worry is the impact on
binary size.

https://codereview.chromium.org/1690493002/diff/80001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/layout/LayoutTheme.cpp (right):

https://codereview.chromium.org/1690493002/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/layout/LayoutTheme.cpp:73:
DEFINE_STATIC_REF(LayoutTheme, layoutThemeMobile,
(LayoutThemeMobile::create()));
On 2016/02/11 at 18:53:44, dgozman wrote:
> This is the meaningful part of the patch.

This seems incorrect anytime we share a render process. For example, if the user
is emulating android on windows and opens a new tab, the new tab can have the
android theme.

I made a testcase for this bug, just emulate and click the link:
http://jsbin.com/nupahu

https://codereview.chromium.org/1690493002/diff/80001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/layout/LayoutThemeDefault.h (right):

https://codereview.chromium.org/1690493002/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/layout/LayoutThemeDefault.h:66: #if
!USE(NEW_THEME)
These theme checks are tricky. WDYT about a pixel test to make sure all the
platforms look the same when emulation is enabled? For example, a page that has
all the controls on it and emulation enabled.

https://codereview.chromium.org/1690493002/diff/80001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/layout/LayoutThemeMobile.h (right):

https://codereview.chromium.org/1690493002/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/layout/LayoutThemeMobile.h:38: #if
!USE(NEW_THEME)
This is basically a "#if !OSX" check... won't this lead to cross-platform
differences in emulation?

(Aside: this NEW_THEME is super confusing. I filed https://crbug.com/586408 to
rename it)

https://codereview.chromium.org/1690493002/diff/80001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/style/ComputedStyle.cpp (right):

https://codereview.chromium.org/1690493002/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/style/ComputedStyle.cpp:86: void
ComputedStyle::clearInitialStyle()
On 2016/02/11 at 18:53:44, dgozman wrote:
> I need some kind of invalidation mechanism which rebuilds initial style
created with DEFINE_STATIC_GLOBAL. I tried to make it least intrusive, but any
ideas are welcome.

Can you help me understand why this needs to be rebuilt? Is this just for
tapHighlightColor or is it for more?

Is it okay that this leaks a full computed style every time?

Is this even safe to change? Won't existing pages that have a reference to this
object get very confused?

[dgozman, 2016-02-19 17:06:49]

Description was changed from

==========
Switch to LayoutThemeMobile when emulating mobile device in DevTools.

This covers subtle differences between rendering on mobile vs desktop platforms.
LayoutTheme decides whether to use mobile theme based on
mobileLayoutThemeEnabled.
Introduced invalidation of initial computed style to take new layout theme into
account.

BUG=585459,543356
==========

to

==========
Switch to LayoutThemeMobile when emulating mobile device in DevTools.

This covers subtle differences between rendering on mobile vs desktop platforms.
LayoutTheme decides whether to use mobile theme based on
mobileLayoutThemeEnabled.
Introduced invalidation of initial computed style to take new layout theme into
account.

BUG=585459,543356,586408
==========

[dgozman, 2016-02-19 17:41:23]

The CQ bit was checked by dgozman@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-02-19 17:42:12]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1690493002/100001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1690493002/100001

[commit-bot: I haz the power, 2016-02-19 19:09:25]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-02-19 19:09:26]

Dry run: This issue passed the CQ dry run.

[dgozman, 2016-02-19 19:15:16]

Please take another look.

https://codereview.chromium.org/1690493002/diff/80001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/BUILD.gn (right):

https://codereview.chromium.org/1690493002/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/BUILD.gn:241: sources -= [
"layout/LayoutThemeFontProviderDefault.cpp" ]
On 2016/02/12 06:36:14, pdr wrote:
> I'm a little out of my depth with these build changes. My worry is the impact
on
> binary size.

Latest patch makes a 16KB difference on my linux release build.

https://codereview.chromium.org/1690493002/diff/80001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/layout/LayoutTheme.cpp (right):

https://codereview.chromium.org/1690493002/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/layout/LayoutTheme.cpp:73:
DEFINE_STATIC_REF(LayoutTheme, layoutThemeMobile,
(LayoutThemeMobile::create()));
On 2016/02/12 06:36:14, pdr wrote:
> On 2016/02/11 at 18:53:44, dgozman wrote:
> > This is the meaningful part of the patch.
> 
> This seems incorrect anytime we share a render process. For example, if the
user
> is emulating android on windows and opens a new tab, the new tab can have the
> android theme.
> 
> I made a testcase for this bug, just emulate and click the link:
> http://jsbin.com/nupahu

I'm aware of this problem, but redesigning away from statics is too big an
effort not worth it for such a small difference in emulation. We do not pretend
to be 100% equal to android anyway.
Similar story happens with overlay scrollbars, which we switch on per-process
basis.

https://codereview.chromium.org/1690493002/diff/80001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/layout/LayoutThemeDefault.h (right):

https://codereview.chromium.org/1690493002/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/layout/LayoutThemeDefault.h:66: #if
!USE(NEW_THEME)
On 2016/02/12 06:36:14, pdr wrote:
> These theme checks are tricky. WDYT about a pixel test to make sure all the
> platforms look the same when emulation is enabled? For example, a page that
has
> all the controls on it and emulation enabled.

I've reworked this to remove all NEW_THEME checks (and the flag altogether). Now
there should be no concern about differences as the code is exactly the same.
I'd prefer to not add an emulation pixel test which will need
attention/rebaselines from anyone working on layout theme. I think there would
be failures and we'll end up disabling it.

https://codereview.chromium.org/1690493002/diff/80001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/layout/LayoutThemeMobile.h (right):

https://codereview.chromium.org/1690493002/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/layout/LayoutThemeMobile.h:38: #if
!USE(NEW_THEME)
On 2016/02/12 06:36:14, pdr wrote:
> This is basically a "#if !OSX" check... won't this lead to cross-platform
> differences in emulation?
> 
> (Aside: this NEW_THEME is super confusing. I filed https://crbug.com/586408 to
> rename it)

Good point. I've reworked the patch to avoid this flag.

https://codereview.chromium.org/1690493002/diff/80001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/style/ComputedStyle.cpp (right):

https://codereview.chromium.org/1690493002/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/style/ComputedStyle.cpp:86: void
ComputedStyle::clearInitialStyle()
On 2016/02/12 06:36:14, pdr wrote:
> On 2016/02/11 at 18:53:44, dgozman wrote:
> > I need some kind of invalidation mechanism which rebuilds initial style
> created with DEFINE_STATIC_GLOBAL. I tried to make it least intrusive, but any
> ideas are welcome.
> 
> Can you help me understand why this needs to be rebuilt? Is this just for
> tapHighlightColor or is it for more?
I'm only aware of tapHighlightColor, but perhaps something may arise in the
future.
I could try to solve this differently - e.g. by invalidating tapHighlightColor
specifically.

> 
> Is it okay that this leaks a full computed style every time?
It should not, |holder| below takes care of that.

> Is this even safe to change? Won't existing pages that have a reference to
this
> object get very confused?
ComputedStyle is refcounted so all objects holding a raw pointer to it should be
stack allocated.
https://code.google.com/p/chromium/codesearch#search/&q=ComputedStyle%5C*%5B%...

https://codereview.chromium.org/1690493002/diff/100001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/layout/LayoutTheme.cpp (right):

https://codereview.chromium.org/1690493002/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/layout/LayoutTheme.cpp:112: switch (part) {
This whole switch was just indented.

[pdr., 2016-02-23 04:23:03]

Overall this looks very nice.

On 2016/02/19 at 19:15:16, dgozman wrote:
>
https://codereview.chromium.org/1690493002/diff/80001/third_party/WebKit/Sour...
> third_party/WebKit/Source/core/style/ComputedStyle.cpp:86: void
ComputedStyle::clearInitialStyle()
> On 2016/02/12 06:36:14, pdr wrote:
> > On 2016/02/11 at 18:53:44, dgozman wrote:
> > > I need some kind of invalidation mechanism which rebuilds initial style
> > created with DEFINE_STATIC_GLOBAL. I tried to make it least intrusive, but
any
> > ideas are welcome.
> > 
> > Can you help me understand why this needs to be rebuilt? Is this just for
> > tapHighlightColor or is it for more?
> I'm only aware of tapHighlightColor, but perhaps something may arise in the
future.
> I could try to solve this differently - e.g. by invalidating tapHighlightColor
specifically.

Can you try this approach? I don't see any way the current approach can break
but it's tricky whereas just setting tapHighlightColor is straightforward.

[dgozman, 2016-02-23 19:21:35]

Could you please take another look?

> Can you try this approach? I don't see any way the current approach can break
> but it's tricky whereas just setting tapHighlightColor is straightforward.
Done. I'm worried that something may be overlooked in the future, but
probability is small enough.

[pdr., 2016-02-23 23:54:37]

On 2016/02/23 at 19:21:35, dgozman wrote:
> Could you please take another look?
> 
> > Can you try this approach? I don't see any way the current approach can
break
> > but it's tricky whereas just setting tapHighlightColor is straightforward.
> Done. I'm worried that something may be overlooked in the future, but
probability is small enough.

LGTM

[dgozman, 2016-02-24 00:50:25]

The CQ bit was checked by dgozman@chromium.org

[commit-bot: I haz the power, 2016-02-24 00:55:55]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1690493002/120001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1690493002/120001

[commit-bot: I haz the power, 2016-02-24 01:18:23]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-02-24 01:18:24]

Try jobs failed on following builders:
  chromium_presubmit on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[dgozman, 2016-02-24 01:28:29]

Nico, could you please take a look at build files?

I'm missing OWNER review for these:
third_party/WebKit/Source/config.gni
third_party/WebKit/Source/build/features.gypi

Thanks,
Dmitry

[Nico, 2016-02-24 01:36:58]

these 2 files lgtm but please mention in the cl description that this gets rid
of the NEW_THEME define (and how it does that)?

[dgozman, 2016-02-24 02:25:43]

Description was changed from

==========
Switch to LayoutThemeMobile when emulating mobile device in DevTools.

This covers subtle differences between rendering on mobile vs desktop platforms.
LayoutTheme decides whether to use mobile theme based on
mobileLayoutThemeEnabled.
Introduced invalidation of initial computed style to take new layout theme into
account.

BUG=585459,543356,586408
==========

to

==========
Switch to LayoutThemeMobile when emulating mobile device in DevTools.

This covers subtle differences between rendering on mobile vs desktop platforms
(see bugs).

LayoutTheme decides whether to use mobile theme based on
mobileLayoutThemeEnabled.
To accomplish this, NEW_THEME build flag was removed. Instead, non-null Theme*
is passed to
LayoutTheme as equivalent to USE(NEW_THEME), and LayoutTheme decides which code
path to use.
Only LayoutThemeMac passes non-null Theme* since NEW_THEME was only implemented
on mac.

Introduced ComputedStyle::invalidateInitialStyle to recalculate static values
which may be
affected by LayoutTheme change.

BUG=585459,543356,586408
==========

[dgozman, 2016-02-24 02:27:05]

On 2016/02/24 01:36:58, Nico wrote:
> these 2 files lgtm but please mention in the cl description that this gets rid
> of the NEW_THEME define (and how it does that)?

Good idea! I've updated the description.
Thanks.

[dgozman, 2016-02-24 02:27:27]

The CQ bit was checked by dgozman@chromium.org

[commit-bot: I haz the power, 2016-02-24 02:30:45]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1690493002/120001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1690493002/120001

[commit-bot: I haz the power, 2016-02-24 02:54:54]

Description was changed from

==========
Switch to LayoutThemeMobile when emulating mobile device in DevTools.

This covers subtle differences between rendering on mobile vs desktop platforms
(see bugs).

LayoutTheme decides whether to use mobile theme based on
mobileLayoutThemeEnabled.
To accomplish this, NEW_THEME build flag was removed. Instead, non-null Theme*
is passed to
LayoutTheme as equivalent to USE(NEW_THEME), and LayoutTheme decides which code
path to use.
Only LayoutThemeMac passes non-null Theme* since NEW_THEME was only implemented
on mac.

Introduced ComputedStyle::invalidateInitialStyle to recalculate static values
which may be
affected by LayoutTheme change.

BUG=585459,543356,586408
==========

to

==========
Switch to LayoutThemeMobile when emulating mobile device in DevTools.

This covers subtle differences between rendering on mobile vs desktop platforms
(see bugs).

LayoutTheme decides whether to use mobile theme based on
mobileLayoutThemeEnabled.
To accomplish this, NEW_THEME build flag was removed. Instead, non-null Theme*
is passed to
LayoutTheme as equivalent to USE(NEW_THEME), and LayoutTheme decides which code
path to use.
Only LayoutThemeMac passes non-null Theme* since NEW_THEME was only implemented
on mac.

Introduced ComputedStyle::invalidateInitialStyle to recalculate static values
which may be
affected by LayoutTheme change.

BUG=585459,543356,586408
==========

[commit-bot: I haz the power, 2016-02-24 02:54:55]

Committed patchset #7 (id:120001)

[commit-bot: I haz the power, 2016-02-24 02:56:22]

Description was changed from

==========
Switch to LayoutThemeMobile when emulating mobile device in DevTools.

This covers subtle differences between rendering on mobile vs desktop platforms
(see bugs).

LayoutTheme decides whether to use mobile theme based on
mobileLayoutThemeEnabled.
To accomplish this, NEW_THEME build flag was removed. Instead, non-null Theme*
is passed to
LayoutTheme as equivalent to USE(NEW_THEME), and LayoutTheme decides which code
path to use.
Only LayoutThemeMac passes non-null Theme* since NEW_THEME was only implemented
on mac.

Introduced ComputedStyle::invalidateInitialStyle to recalculate static values
which may be
affected by LayoutTheme change.

BUG=585459,543356,586408
==========

to

==========
Switch to LayoutThemeMobile when emulating mobile device in DevTools.

This covers subtle differences between rendering on mobile vs desktop platforms
(see bugs).

LayoutTheme decides whether to use mobile theme based on
mobileLayoutThemeEnabled.
To accomplish this, NEW_THEME build flag was removed. Instead, non-null Theme*
is passed to
LayoutTheme as equivalent to USE(NEW_THEME), and LayoutTheme decides which code
path to use.
Only LayoutThemeMac passes non-null Theme* since NEW_THEME was only implemented
on mac.

Introduced ComputedStyle::invalidateInitialStyle to recalculate static values
which may be
affected by LayoutTheme change.

BUG=585459,543356,586408

Committed: https://crrev.com/638717eea162abcacb1f797faeafa3df6f85456a
Cr-Commit-Position: refs/heads/master@{#377198}
==========

[commit-bot: I haz the power, 2016-02-24 02:56:24]

Patchset 7 (id:??) landed as
https://crrev.com/638717eea162abcacb1f797faeafa3df6f85456a
Cr-Commit-Position: refs/heads/master@{#377198}