Mac: Fix another occurence of the two-windows-have-key-status bug

Mac: Fix another occurrence of the two-windows-have-key-status bug

Message Center popups (notifications) create an NSPanel with
NSNonactivatingPanelMask in its styleMask. This is documented as "The panel
can receive keyboard input without activating the owning application."

However, for these popups, the window reports `NO` from canBecomeKeyWindow. So
it's actually impossible for the popup to get key status anyway. This seems to
confuse Cocoa into this bad two-key-window state under an obscure set of repro
steps involving Hangouts. So, remove NSNonactivatingPanelMask.

However, usually Panels (also) obey a "not-visible-unless-application-is"
rule. Simply removing NSNonactivatingPanelMask will cause notification popups
to not be visible unless Chrome is active, which would be bad. To avoid this,
just use a regular NSWindow instead of an NSPanel.

BUG=459306
TEST=See repro case in http://crbug.com/459306#c38 . Shouldn't happen after this.

Committed: https://crrev.com/ba96ee71b35d61b5dfcecc01a5c5f1568ed001c8
Cr-Commit-Position: refs/heads/master@{#343782}

[tapted, 2015-08-11 06:49:38]

tapted@chromium.org changed reviewers:
+ dewittj@chromium.org, rsesek@chromium.org

[tapted, 2015-08-11 07:35:09]

Hi Robert and Justin please take a look.

Of course... this goes back to things before http://crrev.com/15969027 landed.
So a concern would be whether there's a regression in http://crbug.com/243128
(or something else) but it doesn't look like
click-outside-notificaiton-to-dismiss is the norm any longer (and there's a CL
that adds back the event tap attached to that bug anyway). I.e. the current
behaviour wrt this doesn't seem to change with this CL.

Then, I've been chatting to myself for over two hours now and haven't noticed
anything else strange that might result from switching back to an NSWindow.

Repro steps in http://crbug.com/459306#c38 . They are involved, but reliable.
And I've mashed through them pretty hard with this patch in: pretty sure this
will fix it.

Thanks!

[dewittj, 2015-08-11 18:08:49]

I defer to rsesek, as long as existing behavior/appearance remains then lgtm

[tapted, 2015-08-17 01:31:48]

rsesek: hopeful ping?

[Robert Sesek, 2015-08-17 15:35:41]

LGTM

I changed this from NSWindow to NSPanel and added that style mask here:
https://chromium.googlesource.com/chromium/src/+/338bcfd75953ebc2c1fd0084ecae...

I'm guessing -canBecomeKeyWindow returns NO from NSBorderlessWindowMask being
set? I tested this with fullscreen and things seem OK. The original bug for that
change also mentioned multiple monitors, but I have no way to test that.

[Robert Sesek, 2015-08-17 18:15:44]

On 2015/08/17 01:31:48, tapted wrote:
> rsesek: hopeful ping?

Also sorry for the delay; I was at an offsite last week.

[tapted, 2015-08-17 23:43:12]

Thanks all! Here's hoping this is the last repro for http://crbug.com/459306 and
that bug can stop haunting me. (I might try to get this merged back into m45
after waiting for a bit...)

On 2015/08/17 15:35:41, Robert Sesek wrote:
> LGTM
> 
> I changed this from NSWindow to NSPanel and added that style mask here:
>
https://chromium.googlesource.com/chromium/src/+/338bcfd75953ebc2c1fd0084ecae...

Yup - I did some spelunking around those linked bugs (see #msg2).

> I'm guessing -canBecomeKeyWindow returns NO from NSBorderlessWindowMask being
> set?

Yep - exactly.

> I tested this with fullscreen and things seem OK. The original bug for that
> change also mentioned multiple monitors, but I have no way to test that.

I'm a dual monitor devotee :). Mashed around quite a bit - couldn't detect any
behavioural differences versus stable channel. Used Hangouts as well as the
variety of notifications in
https://chrome.google.com/webstore/detail/notifications-galore/gclcddgeeaknfl...


On 2015/08/17 18:15:44, Robert Sesek wrote:
> On 2015/08/17 01:31:48, tapted wrote:
> > rsesek: hopeful ping?
> 
> Also sorry for the delay; I was at an offsite last week.

No worries! (So was I :3)

[tapted, 2015-08-17 23:43:35]

The CQ bit was checked by tapted@chromium.org

[commit-bot: I haz the power, 2015-08-17 23:44:51]

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

[commit-bot: I haz the power, 2015-08-18 00:31:16]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2015-08-18 00:32:19]

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