https://codereview.chromium.org/1954853002/

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ffeee4dcafd17d3658c3c659cf93aa49dcc90da8

commit ffeee4dcafd17d3658c3c659cf93aa49dcc90da8
Author: xdai <xdai@chromium.org>
Date: Mon May 09 20:30:48 2016

When user presses Ctrl-N, we should use the current active window's profile to determine on which profile we should open a new window.

BUG= 608840 

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

[modify] https://crrev.com/ffeee4dcafd17d3658c3c659cf93aa49dcc90da8/chrome/browser/ui/ash/chrome_new_window_delegate.cc
[add] https://crrev.com/ffeee4dcafd17d3658c3c659cf93aa49dcc90da8/chrome/browser/ui/ash/chrome_new_window_delegate_browsertest.cc
[modify] https://crrev.com/ffeee4dcafd17d3658c3c659cf93aa49dcc90da8/chrome/chrome_tests.gypi

Verified on ChromeOS 8481.0.0, 53.0.2773.0

xdai@, now the behavior is "New window for profile #2 pops on desktop #2" after following the repro steps, is the behavior now consistent with your expectation?

warx@, no, I don't think it's the correct behavior. With your CL https://codereview.chromium.org/2599833003/ in place, does it fix this issue?

It's broken again. Reopen it and assign to warx@ since he is working on another related issue: Issue 675265

The reporter's bug now becomes:

What steps will reproduce the problem?
(1) Have 2 profiles on Chrome OS
(2) Login to profile #1
(3) Login to second profile #2 (i.e. CrOS multi-profile)
(4) Move a window from profile #2 to #1's desktop (right-click window + "Move Window to Profile #1")
(5) Focus profile #2's window and hit ctrl-N

What is the expected output?
New window for profile #2 pops on desktop #1.

What do you see instead?
New window for profile #2 pops on desktop #2.

Bisect shows the broken CL is https://codereview.chromium.org/2434463004/

For issue 675265, the regression is brought by removing chrome::FindBrowserWithWindow(ash::wm::GetActiveWindow()), instead using BrowserList::GetInstance()->GetLastActive(). That is not right, ash::wm::GetActiveWindow is to get active window on primary root window. BrowserList::GetInstance()->GetLastActive() does not guarantee for this.

For comment 8 regression, I still don't know why it regresses, which doesn't lead to the right fix now. +erg@, any idea for ChromeNewWindowClient on chromeos-multi-user use case?

The current cl is in https://codereview.chromium.org/2644733004/, still in progress.

No, but I can infodump on what I was doing in that patch. We're currently trying to split ash out of the chrome process; code in //c/b/ui/ash/ shouldn't have new dependencies on //ash outside of //ash/public, and we're trying to drive the current ones to zero so we can make //ash/ a separate binary.

Along these lines, if chrome::FindBrowserWithWindow(ash::wm::GetActiveWindow()) isn't equivalent to BrowserList::GetInstance()->GetLastActive(), then there needs to be something that is without reaching into ash:: directly, only communicating over a mojo channel.

ash::wm::GetActiveWindow() is simply using AtivationClient. You should be able to get the active aura window from there.

It is fixed in  issue 690160 .

9532.0.0, 60.0.3092.0