TrayUser::GetTrayIndex method removed as not necessary. Swich->Switch renamed.

TrayUser::GetTrayIndex method removed as not necessary.
Swich->Switch renamed.

BUG=467907
Committed: https://crrev.com/819c79ba0f391efe03f49b1a21f109699bbe9723
Cr-Commit-Position: refs/heads/master@{#321763}

[merkulova, 2015-03-20 13:21:52]

merkulova@chromium.org changed reviewers:
+ skuhne@chromium.org

[merkulova, 2015-03-20 13:30:21]

Stefan, I removed the method as it seems unnecessary. Also it caused the bug
provided (as IsMultiProfilesEnabled is changing in the middle of the session
because of async way of getting the child account status).

Tested within multiprofile session. Tray items corresponding to user profiles
appear in LRU order upside down. Is there still a case where GetTrayIndex is
required?
 
There was definitely something wrong about the method usage as we were comparing
its result with number of logged in users expecting to process only tray items
for logged in users. And case of mutiprofile_index_ = 0; GetTrayIndex() = 9;
logged_in_users = 1 would be broken then.

[Mr4D (OOO till 08-26), 2015-03-21 20:59:16]

Please check also the Multi User setting (not multi profile) - just to make sure
that that is also working properly! If that works - lgtm

https://codereview.chromium.org/1023183002/diff/1/ash/system/user/tray_user.cc
File ash/system/user/tray_user.cc (left):

https://codereview.chromium.org/1023183002/diff/1/ash/system/user/tray_user.c...
ash/system/user/tray_user.cc:294: if
(!shell->delegate()->IsMultiProfilesEnabled())
Hmm. We have this other multi profile mode (where one user logs in but uses
different cookie jars vs. havig multiple profiles landed). With that this
behavior changes. If you have tested the multiple profile mode (and not the
multi cookie jars) this should be fine.

https://codereview.chromium.org/1023183002/diff/1/chrome/browser/ui/ash/multi...
File chrome/browser/ui/ash/multi_user/user_switch_animator_chromeos.h (right):

https://codereview.chromium.org/1023183002/diff/1/chrome/browser/ui/ash/multi...
chrome/browser/ui/ash/multi_user/user_switch_animator_chromeos.h:26: class
UserSwitchAnimatorChromeOS {
Oh wow. Thanks for fixing the typo! Amazing that no one has noticed!

I am fine with folding this into one CL, but I got already complaints about it.
So you might consider in the future to do that in a separate CL. For now this is
good.

[merkulova, 2015-03-23 09:53:55]

What do you mean by Multi user setting?

If it's gaia multi-login, then it's fine as it doesn't affect ChromeOS tray.

https://codereview.chromium.org/1023183002/diff/1/ash/system/user/tray_user.cc
File ash/system/user/tray_user.cc (left):

https://codereview.chromium.org/1023183002/diff/1/ash/system/user/tray_user.c...
ash/system/user/tray_user.cc:294: if
(!shell->delegate()->IsMultiProfilesEnabled())
On 2015/03/21 20:59:16, Mr4D wrote:
> Hmm. We have this other multi profile mode (where one user logs in but uses
> different cookie jars vs. havig multiple profiles landed). With that this
> behavior changes. If you have tested the multiple profile mode (and not the
> multi cookie jars) this should be fine.

I think you mean multi-login. It doesn't influence ChromeOS tray. I tested
multiprofile mode.

[merkulova, 2015-03-23 11:36:12]

The CQ bit was checked by merkulova@chromium.org

[commit-bot: I haz the power, 2015-03-23 11:36:20]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1023183002/1

[commit-bot: I haz the power, 2015-03-23 13:01:47]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2015-03-23 13:02:13]

Patchset 1 (id:??) landed as
https://crrev.com/819c79ba0f391efe03f49b1a21f109699bbe9723
Cr-Commit-Position: refs/heads/master@{#321763}