UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 YaBrowser/17.3.1.407 (beta) Yowser/2.5 Safari/537.36

Steps to reproduce the problem:
1. You need two Spaces for the bug to reproduce, and there needs to be a Chromium window on each of them, and they need to be BOTH active on their respective space. 
2. Open a site that takes a while to load on one of Chromium windows (http://pikabu.ru works reliably for me), and either navigate to it or refresh the page if it's already open.
3. After navigation/refreshing QUICKLY switch the Space to the other one.
4. Ensure that Chromium window has focus on this space.

If you have performed this sufficiently quickly, the Space will be changed without an explicit action on your part.

What is the expected behavior?
Space should not change without explicit user action.

What went wrong?
StatusBubbleViews::StatusView is the culprit. It will call Widget::ShowInactive(), which will invoke [window_ orderWindow:NSWindowAbove relativeTo:parent_window_number], which will in turn switch the Space (if Chromium is the frontmost application, that's why a second active Chromium window is required in order to reproduce the issue).

StatusBubbleViews::StatusView performs weirdly: it could set Widget's opacity to 0, call ShowInactive() which is immediately followed by Hide().

It's possible to work-around the issue by checking parent NSWindow's -isOnActiveSpace before calling -orderWindow:relativeTo:, but it seems kludgy. A better solution would be for  StatusBubbleViews::StatusView to not call ShowInactive when it's not actually required.

Did this work before? N/A 

Chrome version: 58.0.3008.0  Channel: stable
OS Version: OS X 10.12.3
Flash Version: