Bulk-labelling blockers for Phase2:  Issue 603373 

bulk-tagging Phase2 for M-53

Moving this nonessential bug to the next milestone.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This also applies to
 - Print Preview
 - Collected Cookies

Moving this to Pri-3. Probably an easy fix, but I don't know if should be a blocker. My worry is that doing this with the rest of Harmony might cause people to think it's a regression caused by Harmony rather than something intentional. Needs to go through ui-review in any case.

At least part needs to be a blocker - the fact that the panel does not NSBeep() when this happens is an a11y issue (on the Mac the NSBeep() optionally gets turned into a screen flash).

In Safari, if I go to https://www.google.com.au and click the padlock icon I get a sheet.

Clicking outside it does _not_ beep. Pressing ESC does.

Similarly Cmd+s in Safari shows the save dialog. Click outside: no beep. ESC dismisses.

I see. The pulsing is meant to notify the user that they're in a modal dialog and can't do anything until they are out of that dialog. The proper behavior, if one wants to inform the user of such a condition, is NSBeep(). So I was saying that the dialog should NSBeep() but losing site of the fact that standard dialogs don't do anything in this case.

Helene/Shrike: What's the behaviour we want?

Removing the pulse is easy, but it was added on Mac very intentionally. Feels like a regression to remove it, imo.

 - Sheets in Safari (e.g. Cmd+s) do not beep or pulse.
 - TabModals in Safari (e.g. https://httpbin.org/basic-auth/user/passwd ) do not beep or pulse.
    * But also Safari's dialog is not actually a dialog in this case but a nested NSView which has weird clipping issues.
 - Only AppModal windows in Safari (e.g. Cmd+o) beep.

Note Chrome's open dialog (Cmd+o) is a sheet in Chrome - not an AppModal dialog.

Also I'm removing all the MacViews tags. MacCocoa TabModal dialogs do this - the Views ones just use the same animation.

Deleted: Screen Shot 2017-07-17 at 3.53.12 pm.png 39.3 KB

	Screen Shot 2017-07-17 at 3.53.12 pm.png 39.3 KB View Download

The pulsing is just not very Mac-like.

If we feel we have to do something I would just do a system beep.

Discussed with helenepark@:
- Could you review the shadow motion in the motion spec? go/harmony-shadow-motion
- For the time being, no beeping and no pulsing is good.

Thanks!

Hello hwi@,

Are you talking to me in c#17? I think the shadow motion is better than the pulsing. I don't know what it'll take to implement.

 go/harmony-shadow-motion does look nice... it's straightforward in aura, but currently on Mac (i.e. MacViews), the Mac WindowServer process draws our shadow, and it's "impossible" to change since it's embedded in macOS -- we'd need Apple to write it for us ;)

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

We've lived with this for 2+ years now, so it's unlikely to get fixed. Closing out.

Also with --enable-features=ViewsBrowserWindows they don't currently pulse... Investigations in  Issue 767743  may influence this though.