Relaunch Chrome in metro-mode with the help of a helper process.

Implement relaunch for Metro chrome.

The relaunch is accomplished by spawining off delegate_execute.exe which waits for Chrome to exit an then reactivates it by way of the start menu shortcut.

BUG=125434, 125854
TEST=tweak a flag in chrome://flags in metro Chrome and hit the relaunch button.

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=149884

[cpu_(ooo_6.6-7.5), 2012-06-29 21:32:39]

before we go this route I would like to understand what made the previous
(simpler?) approach not work.

For example, would relaunching from CoreWindow's main thread once chrome main
thread is signaled be simpler, nicer?

Ping me for a chat.

http://codereview.chromium.org/10699040/diff/1/chrome/browser/first_run/upgra...
File chrome/browser/first_run/upgrade_util_win.cc (right):

http://codereview.chromium.org/10699040/diff/1/chrome/browser/first_run/upgra...
chrome/browser/first_run/upgrade_util_win.cc:65: FilePath
GetRelauncherPath(base::Environment* env,
needs a better name, like GetMetroRelauncherPath

http://codereview.chromium.org/10699040/diff/1/chrome/browser/first_run/upgra...
chrome/browser/first_run/upgrade_util_win.cc:68: 
kill this empty line

[grt (UTC plus 2), 2012-06-30 03:13:46]

On 2012/06/29 21:32:39, cpu wrote:
> before we go this route I would like to understand what made the previous
> (simpler?) approach not work.
> 
> For example, would relaunching from CoreWindow's main thread once chrome main
> thread is signaled be simpler, nicer?
> 
> Ping me for a chat.

Thanks for the pre-emptive review.  I hadn't sent out mail for it yet since it
isn't reliably working as expected.  It seems that there's still some state held
outside of chrome that interferes with the relaunch.  It initially seemed that
waiting for chrome.exe to exit in the relauncher was enough to let a call to
IApplicationActivationManager::ActivateApplication succeed, but it appears to be
flaky.  Sometimes it works, yet sometimes I just get the white screen with the
Chrome logo in the middle (and our DelegateExecute handler's CommandExecuteImpl
class is never created).

I've also just tried a call to IPackageDebugSettings::TerminateAllProcesses from
within the relauncher after waiting for chrome.exe to exit, and this causes the
shell to kill the relauncher itself.  I wonder if this is because I'm not
breaking the relauncher out of metro Chrome's job.

So, yeah, let's chat on Tuesday.

[grt (UTC plus 2), 2012-07-31 21:44:03]

Please take a fresh look.

https://chromiumcodereview.appspot.com/10699040/diff/1/chrome/browser/first_r...
File chrome/browser/first_run/upgrade_util_win.cc (right):

https://chromiumcodereview.appspot.com/10699040/diff/1/chrome/browser/first_r...
chrome/browser/first_run/upgrade_util_win.cc:65: FilePath
GetRelauncherPath(base::Environment* env,
On 2012/06/29 21:32:39, cpu wrote:
> needs a better name, like GetMetroRelauncherPath

Done.

https://chromiumcodereview.appspot.com/10699040/diff/1/chrome/browser/first_r...
chrome/browser/first_run/upgrade_util_win.cc:68: 
On 2012/06/29 21:32:39, cpu wrote:
> kill this empty line

Done.

https://chromiumcodereview.appspot.com/10699040/diff/1/chrome/browser/first_r...
chrome/browser/first_run/upgrade_util_win.cc:127:
ignore_result(process_handle.Take());
It's my understanding that both processes need to release their copy of
inherited handles independently, so I believe that this line of code actually
caused a leak rather than preventing a double-free.  Does this sound right to
you?

[grt (UTC plus 2), 2012-08-02 19:51:59]

+brettw for base OWNERShip

[brettw, 2012-08-02 19:56:49]

I'm scared of putting pointer to string in base code. Can you just put the
necessary thing in your .cc file where you need it?

[grt (UTC plus 2), 2012-08-02 20:16:05]

On 2012/08/02 19:56:49, brettw wrote:
> I'm scared of putting pointer to string in base code. Can you just put the
> necessary thing in your .cc file where you need it?

sure, i can do that.  carlos: do you happen to know if a HANDLE is always 32
bits even in a 64-bit build?  if so, i can safely do some casts and get rid of
the base changes.

[siggi_google.com, 2012-08-02 20:29:56]

Kernel handles can safely be considered 32 bit:
http://msdn.microsoft.com/en-us/library/windows/desktop/ee872017(v=vs.85).aspx



On Thu, Aug 2, 2012 at 4:16 PM, <grt@chromium.org> wrote:

>
> On 2012/08/02 19:56:49, brettw wrote:
>
>> I'm scared of putting pointer to string in base code. Can you just put the
>> necessary thing in your .cc file where you need it?
>>
>
> sure, i can do that.  carlos: do you happen to know if a HANDLE is always
> 32
> bits even in a 64-bit build?  if so, i can safely do some casts and get
> rid of
> the base changes.
>
>
https://chromiumcodereview.**appspot.com/10699040/<https://chromiumcodereview...
>

[grt (UTC plus 2), 2012-08-02 21:24:47]

Thanks, Siggi1.  Switched to treating a HANDLE as a uint.  Please continue your
review, kind sir(s).

[cpu_(ooo_6.6-7.5), 2012-08-02 22:12:38]

lgtm

[commit-bot: I haz the power, 2012-08-03 09:18:31]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/grt@chromium.org/10699040/14002

[commit-bot: I haz the power, 2012-08-03 09:18:34]

Failed to apply patch for chrome/common/chrome_switches.cc:
While running patch -p1 --forward --force;
patching file chrome/common/chrome_switches.cc
Hunk #1 FAILED at 1497.
1 out of 1 hunk FAILED -- saving rejects to file
chrome/common/chrome_switches.cc.rej

[commit-bot: I haz the power, 2012-08-03 09:30:06]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/grt@chromium.org/10699040/17002

[commit-bot: I haz the power, 2012-08-03 09:30:12]

Presubmit check for 10699040-17002 failed and returned exit status 1.

Running presubmit commit checks ...

** Presubmit ERRORS **
Missing LGTM from an OWNER for files in these directories:
    chrome

Presubmit checks took 3.2s to calculate.

[grt (UTC plus 2), 2012-08-03 13:51:36]

+brettw for chrome OWNERS approval.  Please check the CQ box if you approve. 
Thanks.

[sky, 2012-08-03 17:02:58]

LGTM

[commit-bot: I haz the power, 2012-08-03 17:07:57]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/grt@chromium.org/10699040/17002

[commit-bot: I haz the power, 2012-08-03 18:52:29]

Change committed as 149884