Decouple IsMetroProcess() calls, introducing IsSingleWindowMetroMode().

Decouple IsMetroProcess() calls, introducing IsSingleWindowMetroMode().

Many things were calling IsMetroProcess() when the intent was really to turn things ON/OFF for Metro Chrome, this does not apply to Metro Ash however.

Details of how this has been decoupled can be found at https://docs.google.com/spreadsheet/ccc?key=0AtwXJ4IPPZBAdEdaWUpLYk9IM3I1bTJleFJobXN3Z2c (more decoupling will be needed later and has been listed in separate columns on this spreadsheet; however for now this CL only applies the first column).

Also introduces win8_util where some other win8-specific things currently in base should eventually also be refactored into.

BUG=151718
TEST=This makes a bunch of things just work now in Metro Ash :).


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

[gab, 2012-11-30 18:06:15]

cpu/robertshield: Please review the spreadsheet and matching code of which
features are affected by this new call.

brettw: OWNER aproval for new win8/util DEPS in content/.
gene: OWNER approval for new win8/util DEPS in printing/.

Thanks,
Gab

[robertshield, 2012-12-03 19:48:47]

builders look unhappy, couple of nits

https://codereview.chromium.org/11411286/diff/3001/chrome/browser/ui/views/fr...
File chrome/browser/ui/views/frame/browser_view.cc (right):

https://codereview.chromium.org/11411286/diff/3001/chrome/browser/ui/views/fr...
chrome/browser/ui/views/frame/browser_view.cc:140: #elif defined(OS_WIN)
I feel that this would be more readable as a standalone block:
#if defined(OS_WIN) && !defined(USE_AURA)

Alternatively, at least add a comment to the end along the lines of //
!defined(USE_AURA).

https://codereview.chromium.org/11411286/diff/3001/chrome/browser/ui/views/fr...
chrome/browser/ui/views/frame/browser_view.cc:1793:
GetWidget()->DebugToggleFrameType();
this introduces a change in behaviour for the line above. Is that intended?

[cpu_(ooo_6.6-7.5), 2012-12-03 20:56:26]

Overall I like the change, there are a few issues:

0- This changes is big and it does not need to, I would like to see the trivial
ones done first in a CL and then the rest in a second CL. Which ones which I've
tried to mark, but you could be even more conservative.

1- Most of the comments next to the changes need a slight rewording or be
removed, as win8 is not a exotic thing anymore, use your judgement.

2- Places where we show a native dialog need to stay as there were, it is
incorrect to show a dialog in ash unless the parent is the corewindow, it cannot
be chrome's top window or the desktop or have windows figure it out.

3- Some places seem to have an extra metro.h but I am not sure unless I read the
whole file.

https://codereview.chromium.org/11411286/diff/3001/chrome/browser/extensions/...
File chrome/browser/extensions/extension_prefs.cc (right):

https://codereview.chromium.org/11411286/diff/3001/chrome/browser/extensions/...
chrome/browser/extensions/extension_prefs.cc:1225: // We don't support app
windows in windows 8 metro mode.
the comment needs rewording

https://codereview.chromium.org/11411286/diff/3001/chrome/browser/ui/browser_...
File chrome/browser/ui/browser_win.cc (right):

https://codereview.chromium.org/11411286/diff/3001/chrome/browser/ui/browser_...
chrome/browser/ui/browser_win.cc:8: #include "base/win/metro.h"
do we need metro.h here?

https://codereview.chromium.org/11411286/diff/3001/chrome/browser/ui/browser_...
chrome/browser/ui/browser_win.cc:67: 
these two functions should call a single local function that takes a Brower* and
a Profile*

https://codereview.chromium.org/11411286/diff/3001/chrome/browser/ui/extensio...
File chrome/browser/ui/extensions/application_launch.cc (right):

https://codereview.chromium.org/11411286/diff/3001/chrome/browser/ui/extensio...
chrome/browser/ui/extensions/application_launch.cc:117: // them. We attempt to
reuse an existing Browser window.
comment needs rewording

https://codereview.chromium.org/11411286/diff/3001/chrome/browser/ui/toolbar/...
File chrome/browser/ui/toolbar/wrench_menu_model.cc (right):

https://codereview.chromium.org/11411286/diff/3001/chrome/browser/ui/toolbar/...
chrome/browser/ui/toolbar/wrench_menu_model.cc:479: // In Metro, we only show
the New Window options if there isn't already
reword

https://codereview.chromium.org/11411286/diff/3001/chrome/browser/ui/views/fr...
File chrome/browser/ui/views/frame/browser_view.cc (right):

https://codereview.chromium.org/11411286/diff/3001/chrome/browser/ui/views/fr...
chrome/browser/ui/views/frame/browser_view.cc:191: // In Windows 8 metro mode
the window is always maximized (without the
reword

https://codereview.chromium.org/11411286/diff/3001/chrome/browser/ui/views/fr...
chrome/browser/ui/views/frame/browser_view.cc:1557: // If we are in windows
metro-mode, we can't allow popup windows.
reword

https://codereview.chromium.org/11411286/diff/3001/chrome/browser/ui/views/fr...
File chrome/browser/ui/views/frame/opaque_browser_frame_view.cc (right):

https://codereview.chromium.org/11411286/diff/3001/chrome/browser/ui/views/fr...
chrome/browser/ui/views/frame/opaque_browser_frame_view.cc:121: #if
defined(OS_WIN)
not familiar with this particular change, consider leaving this out and adding
it in a second CL.

https://codereview.chromium.org/11411286/diff/3001/chrome/browser/ui/views/hu...
File chrome/browser/ui/views/hung_renderer_view_win.cc (right):

https://codereview.chromium.org/11411286/diff/3001/chrome/browser/ui/views/hu...
chrome/browser/ui/views/hung_renderer_view_win.cc:7: #include "base/win/metro.h"
is metro.h necessary?

https://codereview.chromium.org/11411286/diff/3001/chrome/browser/ui/views/om...
File chrome/browser/ui/views/omnibox/omnibox_view_win.cc (right):

https://codereview.chromium.org/11411286/diff/3001/chrome/browser/ui/views/om...
chrome/browser/ui/views/omnibox/omnibox_view_win.cc:1745:
DCHECK(win8::IsSingleWindowMetroMode());
not familiar with this change, again consider this for a second CL.

https://codereview.chromium.org/11411286/diff/3001/chrome/browser/ui/views/ta...
File chrome/browser/ui/views/tabs/tab_strip.cc (right):

https://codereview.chromium.org/11411286/diff/3001/chrome/browser/ui/views/ta...
chrome/browser/ui/views/tabs/tab_strip.cc:1065: // It doesn't make sense to drag
tabs out on metro.
reword

https://codereview.chromium.org/11411286/diff/3001/chrome/browser/ui/views/ta...
File chrome/browser/ui/views/task_manager_view.cc (right):

https://codereview.chromium.org/11411286/diff/3001/chrome/browser/ui/views/ta...
chrome/browser/ui/views/task_manager_view.cc:590: 
FYI, There is a discussion about what task manager to show; the native one
cannot be shown and the webview based should not be shown.

https://codereview.chromium.org/11411286/diff/3001/printing/printing_context_...
File printing/printing_context_win.cc (right):

https://codereview.chromium.org/11411286/diff/3001/printing/printing_context_...
printing/printing_context_win.cc:228: // The system dialog can not be opened
while running in Metro.
this seems incorrect as in ash we don't want this either.

[gab, 2012-12-04 00:19:06]

>Overall I like the change, there are a few issues:

> 0- This changes is big and it does not need to, I would like to see the
trivial ones done first in a CL and then the rest in a second CL. Which ones
which I've tried to mark, but you could be even more conservative.

I've kept this CL to only the win8::SingleWindowMetroMode() changes which I
think are fairly trivial by themselves, I'm happy to keep specific ones out if
you feel strongly.

> 1- Most of the comments next to the changes need a slight rewording or be
removed, as win8 is not a exotic thing anymore, use your judgement.

Done.

> 2- Places where we show a native dialog need to stay as there were, it is
incorrect to show a dialog in ash unless the parent is the corewindow, it cannot
be chrome's top window or the desktop or have windows figure it out.

Don't we want to build an Ash equivalent for them if there isn't already one? We
likely don't want to disable things like task manager, hung renderer view, etc.
on Ash right?

Furthermore, for dialogs for which this is still the case (i.e. that we don't
want in Ash), they should be put in the second column of the spreadsheet as
right now base::win::IsMetroProcess() returns false for them in Ash anyways
(since Robert's recent change where the browser process is no longer considered
immersive).

PTAL at
https://docs.google.com/a/chromium.org/spreadsheet/ccc?key=0AtwXJ4IPPZBAdEdaW...
and let me know if anything appears to be in the wrong column.

> 3- Some places seem to have an extra metro.h but I am not sure unless I read
the whole file.

The only ones with metro.h left are the ones still using base::win:: methods
from metro.h.

Thanks,
Gab

https://codereview.chromium.org/11411286/diff/3001/chrome/browser/extensions/...
File chrome/browser/extensions/extension_prefs.cc (right):

https://codereview.chromium.org/11411286/diff/3001/chrome/browser/extensions/...
chrome/browser/extensions/extension_prefs.cc:1225: // We don't support app
windows in windows 8 metro mode.
On 2012/12/03 20:56:26, cpu wrote:
> the comment needs rewording 

Done.

https://codereview.chromium.org/11411286/diff/3001/chrome/browser/ui/browser_...
File chrome/browser/ui/browser_win.cc (right):

https://codereview.chromium.org/11411286/diff/3001/chrome/browser/ui/browser_...
chrome/browser/ui/browser_win.cc:8: #include "base/win/metro.h"
On 2012/12/03 20:56:26, cpu wrote:
> do we need metro.h here?

Yes, remaining base::win::GetMetroModule() below.

https://codereview.chromium.org/11411286/diff/3001/chrome/browser/ui/browser_...
chrome/browser/ui/browser_win.cc:67: 
On 2012/12/03 20:56:26, cpu wrote:
> these two functions should call a single local function that takes a Brower*
and
> a Profile*

Sure, but I don't feel this is related to this change which simply maps the old
call to the new call.

https://codereview.chromium.org/11411286/diff/3001/chrome/browser/ui/extensio...
File chrome/browser/ui/extensions/application_launch.cc (right):

https://codereview.chromium.org/11411286/diff/3001/chrome/browser/ui/extensio...
chrome/browser/ui/extensions/application_launch.cc:117: // them. We attempt to
reuse an existing Browser window.
On 2012/12/03 20:56:26, cpu wrote:
> comment needs rewording

Done.

https://codereview.chromium.org/11411286/diff/3001/chrome/browser/ui/toolbar/...
File chrome/browser/ui/toolbar/wrench_menu_model.cc (right):

https://codereview.chromium.org/11411286/diff/3001/chrome/browser/ui/toolbar/...
chrome/browser/ui/toolbar/wrench_menu_model.cc:479: // In Metro, we only show
the New Window options if there isn't already
On 2012/12/03 20:56:26, cpu wrote:
> reword

Done.

https://codereview.chromium.org/11411286/diff/3001/chrome/browser/ui/views/fr...
File chrome/browser/ui/views/frame/browser_view.cc (right):

https://codereview.chromium.org/11411286/diff/3001/chrome/browser/ui/views/fr...
chrome/browser/ui/views/frame/browser_view.cc:140: #elif defined(OS_WIN)
On 2012/12/03 19:48:48, robertshield wrote:
> I feel that this would be more readable as a standalone block:
> #if defined(OS_WIN) && !defined(USE_AURA)
> 
> Alternatively, at least add a comment to the end along the lines of //
> !defined(USE_AURA).

Ok, added comment at end of line.

https://codereview.chromium.org/11411286/diff/3001/chrome/browser/ui/views/fr...
chrome/browser/ui/views/frame/browser_view.cc:191: // In Windows 8 metro mode
the window is always maximized (without the
On 2012/12/03 20:56:26, cpu wrote:
> reword

Done.

https://codereview.chromium.org/11411286/diff/3001/chrome/browser/ui/views/fr...
chrome/browser/ui/views/frame/browser_view.cc:1557: // If we are in windows
metro-mode, we can't allow popup windows.
On 2012/12/03 20:56:26, cpu wrote:
> reword

Done.

https://codereview.chromium.org/11411286/diff/3001/chrome/browser/ui/views/fr...
chrome/browser/ui/views/frame/browser_view.cc:1793:
GetWidget()->DebugToggleFrameType();
On 2012/12/03 19:48:48, robertshield wrote:
> this introduces a change in behaviour for the line above. Is that intended?

This is can only ever be called if switches::kDebugEnableFrameToggle (see
definition below) is specified on the command-line. I figured it wasn't worth
adding an extra #if !defined(USE_AURA) around this since if it's broken for aura
builds, the developer should simply not be using this command-line or fix it if
he cares imo... let me know if you feel otherwise.

// Enables a frame context menu item that toggles the frame in and out of glass
// mode (Windows Vista and up only).
const char kDebugEnableFrameToggle[]        = "debug-enable-frame-toggle";

https://codereview.chromium.org/11411286/diff/3001/chrome/browser/ui/views/fr...
File chrome/browser/ui/views/frame/opaque_browser_frame_view.cc (right):

https://codereview.chromium.org/11411286/diff/3001/chrome/browser/ui/views/fr...
chrome/browser/ui/views/frame/opaque_browser_frame_view.cc:121: #if
defined(OS_WIN)
On 2012/12/03 20:56:26, cpu wrote:
> not familiar with this particular change, consider leaving this out and adding
> it in a second CL.

Given it already had #if !defined(USE_AURA); this is keeping the exact same
behavior as before (i.e. always true except on non-ash-Metro-mode).

https://codereview.chromium.org/11411286/diff/3001/chrome/browser/ui/views/hu...
File chrome/browser/ui/views/hung_renderer_view_win.cc (right):

https://codereview.chromium.org/11411286/diff/3001/chrome/browser/ui/views/hu...
chrome/browser/ui/views/hung_renderer_view_win.cc:7: #include "base/win/metro.h"
On 2012/12/03 20:56:26, cpu wrote:
> is metro.h necessary?

Yes, for base::win::GetMetroModule() below.

https://codereview.chromium.org/11411286/diff/3001/chrome/browser/ui/views/om...
File chrome/browser/ui/views/omnibox/omnibox_view_win.cc (right):

https://codereview.chromium.org/11411286/diff/3001/chrome/browser/ui/views/om...
chrome/browser/ui/views/omnibox/omnibox_view_win.cc:1745:
DCHECK(win8::IsSingleWindowMetroMode());
On 2012/12/03 20:56:26, cpu wrote:
> not familiar with this change, again consider this for a second CL.

This was added by ananta in https://codereview.chromium.org/11098077, I don't
think this code path is even used in an AURA build (does the AURA build  use
omnibox_view_win.cc?) and even if it does, I don't think we would be subject to
this bad behavior?

In doubt I can leave this out, but I'd rather keep it all together.

https://codereview.chromium.org/11411286/diff/3001/chrome/browser/ui/views/ta...
File chrome/browser/ui/views/tabs/tab_strip.cc (right):

https://codereview.chromium.org/11411286/diff/3001/chrome/browser/ui/views/ta...
chrome/browser/ui/views/tabs/tab_strip.cc:1065: // It doesn't make sense to drag
tabs out on metro.
On 2012/12/03 20:56:26, cpu wrote:
> reword

Done.

https://codereview.chromium.org/11411286/diff/3001/chrome/browser/ui/views/ta...
File chrome/browser/ui/views/task_manager_view.cc (right):

https://codereview.chromium.org/11411286/diff/3001/chrome/browser/ui/views/ta...
chrome/browser/ui/views/task_manager_view.cc:590: 
On 2012/12/03 20:56:26, cpu wrote:
> FYI, There is a discussion about what task manager to show; the native one
> cannot be shown and the webview based should not be shown.
> 

So making this change only enables (and some other related to task manager in
this CL) showing the Task Manager -- this fails for now as it tries to create a
native window, but in the end we do want a task manager in Ash right?

In fact this change doesn't do much as is anyways since this will run in the
browser process which was already not an immersive process by Robert's recent
redesign.

The purpose of this change is more to highlight which things are meant to be
turned ON/OFF specifically for non-ash Metro mode.

https://codereview.chromium.org/11411286/diff/3001/printing/printing_context_...
File printing/printing_context_win.cc (right):

https://codereview.chromium.org/11411286/diff/3001/printing/printing_context_...
printing/printing_context_win.cc:228: // The system dialog can not be opened
while running in Metro.
On 2012/12/03 20:56:26, cpu wrote:
> this seems incorrect as in ash we don't want this either.

This is already precompiled out for AURA builds (see line 224), might as well
change the method called here as well no?

[cpu_(ooo_6.6-7.5), 2012-12-04 01:00:51]

https://codereview.chromium.org/11411286/diff/3001/chrome/browser/ui/browser_...
File chrome/browser/ui/browser_win.cc (right):

https://codereview.chromium.org/11411286/diff/3001/chrome/browser/ui/browser_...
chrome/browser/ui/browser_win.cc:67: 
It is related. You are adding code that can be de-duplicated, sure duplicated
code was there before but that is besides the point.

Janitorial tasks like that happen to the best of us, just ask grt@

On 2012/12/04 00:19:06, gab wrote:
> On 2012/12/03 20:56:26, cpu wrote:
> > these two functions should call a single local function that takes a Brower*
> and


> > a Profile*
> 
> Sure, but I don't feel this is related to this change which simply maps the
old
> call to the new call.

[cpu_(ooo_6.6-7.5), 2012-12-04 01:11:19]

>> Don't we want to build an Ash equivalent for them if there >> isn't already
one? We
>> likely don't want to disable things like task manager, hung renderer view,
etc.
>> on Ash right?

The generic answer is yes although the specifics might change. For example the
task manager. On windows we have one that uses native hwnd and native listview
common win32 control, for aura on chromeos we have one on top of webview. The
former has been banned from windows (it was used for a bit) because then chrome
is limping the last thing you want is trying to use a webview to kill the gpu.
In chromeos you don't have a choice since we don't have gtk or anything to fall
back on, is "webpages all the way down"

For this codereivew what matter is that a) if we show an hwnd that needs to be
disabled (for the time being) in ash. b) if we show a webview then we probably
can live with it for some time on ash and definitely not in desktop.

From the CL I can't tell what is going to happen. With your change what do you
see?

[cpu_(ooo_6.6-7.5), 2012-12-04 01:17:38]

https://codereview.chromium.org/11411286/diff/3001/chrome/browser/ui/views/om...
File chrome/browser/ui/views/omnibox/omnibox_view_win.cc (right):

https://codereview.chromium.org/11411286/diff/3001/chrome/browser/ui/views/om...
chrome/browser/ui/views/omnibox/omnibox_view_win.cc:1745:
DCHECK(win8::IsSingleWindowMetroMode());
Like I said, all other things equal you should prefer smaller CLs, but if you
insists then add ananta to the review.

On 2012/12/04 00:19:06, gab wrote:
> On 2012/12/03 20:56:26, cpu wrote:
> > not familiar with this change, again consider this for a second CL.
> 
> This was added by ananta in https://codereview.chromium.org/11098077, I don't
> think this code path is even used in an AURA build (does the AURA build  use
> omnibox_view_win.cc?) and even if it does, I don't think we would be subject
to
> this bad behavior?
> 
> In doubt I can leave this out, but I'd rather keep it all together.

[gab, 2012-12-04 18:47:42]

Addressed comments, PTAL.

Thanks,
Gab

https://codereview.chromium.org/11411286/diff/3001/chrome/browser/ui/browser_...
File chrome/browser/ui/browser_win.cc (right):

https://codereview.chromium.org/11411286/diff/3001/chrome/browser/ui/browser_...
chrome/browser/ui/browser_win.cc:67: 
On 2012/12/04 01:00:51, cpu wrote:
> It is related. You are adding code that can be de-duplicated, sure duplicated
> code was there before but that is besides the point.
> 
> Janitorial tasks like that happen to the best of us, just ask grt@

Ok, done.

> 
> On 2012/12/04 00:19:06, gab wrote:
> > On 2012/12/03 20:56:26, cpu wrote:
> > > these two functions should call a single local function that takes a
Brower*
> > and
> 
> 
> > > a Profile*
> > 
> > Sure, but I don't feel this is related to this change which simply maps the
> old
> > call to the new call.
>

https://codereview.chromium.org/11411286/diff/3001/chrome/browser/ui/views/om...
File chrome/browser/ui/views/omnibox/omnibox_view_win.cc (right):

https://codereview.chromium.org/11411286/diff/3001/chrome/browser/ui/views/om...
chrome/browser/ui/views/omnibox/omnibox_view_win.cc:1745:
DCHECK(win8::IsSingleWindowMetroMode());
On 2012/12/04 01:17:39, cpu wrote:
> Like I said, all other things equal you should prefer smaller CLs, but if you
> insists then add ananta to the review.
> 
> On 2012/12/04 00:19:06, gab wrote:
> > On 2012/12/03 20:56:26, cpu wrote:
> > > not familiar with this change, again consider this for a second CL.
> > 
> > This was added by ananta in https://codereview.chromium.org/11098077, I
don't
> > think this code path is even used in an AURA build (does the AURA build  use
> > omnibox_view_win.cc?) and even if it does, I don't think we would be subject
> to
> > this bad behavior?
> > 
> > In doubt I can leave this out, but I'd rather keep it all together.
> 

Ok, leaving out for now.

https://codereview.chromium.org/11411286/diff/3001/chrome/browser/ui/views/ta...
File chrome/browser/ui/views/task_manager_view.cc (right):

https://codereview.chromium.org/11411286/diff/3001/chrome/browser/ui/views/ta...
chrome/browser/ui/views/task_manager_view.cc:590: 
On 2012/12/04 00:19:06, gab wrote:
> On 2012/12/03 20:56:26, cpu wrote:
> > FYI, There is a discussion about what task manager to show; the native one
> > cannot be shown and the webview based should not be shown.
> > 
> 
> So making this change only enables (and some other related to task manager in
> this CL) showing the Task Manager -- this fails for now as it tries to create
a
> native window, but in the end we do want a task manager in Ash right?
> 
> In fact this change doesn't do much as is anyways since this will run in the
> browser process which was already not an immersive process by Robert's recent
> redesign.
> 
> The purpose of this change is more to highlight which things are meant to be
> turned ON/OFF specifically for non-ash Metro mode.

Looks like task_manager_view.cc is already compiled out on AURA builds:
https://code.google.com/searchframe#OAMlx_jo-ck/src/chrome/chrome_browser_ui....

So this is definitely a case of win8::IsSingleWindowMetroMode().

[gab, 2012-12-04 19:04:31]

See comment below.

https://codereview.chromium.org/11411286/diff/3001/chrome/browser/ui/views/om...
File chrome/browser/ui/views/omnibox/omnibox_view_win.cc (right):

https://codereview.chromium.org/11411286/diff/3001/chrome/browser/ui/views/om...
chrome/browser/ui/views/omnibox/omnibox_view_win.cc:1745:
DCHECK(win8::IsSingleWindowMetroMode());
On 2012/12/04 18:47:42, gab wrote:
> On 2012/12/04 01:17:39, cpu wrote:
> > Like I said, all other things equal you should prefer smaller CLs, but if
you
> > insists then add ananta to the review.
> > 
> > On 2012/12/04 00:19:06, gab wrote:
> > > On 2012/12/03 20:56:26, cpu wrote:
> > > > not familiar with this change, again consider this for a second CL.
> > > 
> > > This was added by ananta in https://codereview.chromium.org/11098077, I
> don't
> > > think this code path is even used in an AURA build (does the AURA build 
use
> > > omnibox_view_win.cc?) and even if it does, I don't think we would be
subject
> > to
> > > this bad behavior?
> > > 
> > > In doubt I can leave this out, but I'd rather keep it all together.
> > 
> 
> Ok, leaving out for now.

Reconsidered, leaving it in since this file isn't even compiled in on AURA so
this is definitely the right choice:
https://code.google.com/searchframe#OAMlx_jo-ck/src/chrome/chrome_browser_ui.....

[cpu_(ooo_6.6-7.5), 2012-12-04 21:39:38]

lgtm

[robertshield, 2012-12-04 21:54:49]

lgtm

[gab, 2012-12-04 22:07:39]

Thanks,

@brettw for chrome/ and content/ OWNER approval.
@gene for printing/ OWNER approval.

Cheers!
Gab

[brettw, 2012-12-05 19:16:46]

lgtm

[gene, 2012-12-05 20:35:40]

lgtm

[commit-bot: I haz the power, 2012-12-05 20:38:57]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/gab@chromium.org/11411286/80

[commit-bot: I haz the power, 2012-12-06 00:40:35]

Change committed as 171366

[Dirk Pranke, 2013-02-14 22:27:42]

On 2012/12/06 00:40:35, I haz the power (commit-bot) wrote:
> Change committed as 171366

This change breaks the webkit.org win build, by adding a gyp dependency from
win8.gyp -> chrome.gyp (which we don't check out on those bots). The full
dependency chain is webkit_support -> printing -> win8 -> chrome :(.

I've posted a workaround in https://codereview.chromium.org/12207186/ but I'm
not sure what you'll want to do as a long-term fix. Seems bad that win8 would
depend on chrome?

[gab, 2013-02-15 04:12:43]

I don't think this CL introduced this, but rather
https://chromiumcodereview.appspot.com/12096064

[Dirk Pranke, 2013-02-15 20:50:55]

On 2013/02/15 04:12:43, gab wrote:
> I don't think this CL introduced this, but rather
> https://chromiumcodereview.appspot.com/12096064

Oh, you're right, I read the blame log wrong. Sorry!