Forgot to attach the screen shot.

Deleted: display_resolution1.png 24.2 KB

	display_resolution1.png 24.2 KB View Download

Why are we using a notification for such a critical piece of UI ? We should be handling that in settings. Notification should be informational only.

@sky do you have a design/UX POC for this?

I think tbuckley used to own this unless that should be moved to ovanieva.

re-assigning to myself.

Is this UI behind a flag? I can't repro on canary.

> @sky do you have a design/UX POC for this?

No. I'm not directly working on this UI. I only noticed it when testing changing the display. This was a tip of tree build (meaning it should be in canary). 

Thanks for reporting :)
@ovanieva, please work with UX on this. It cannot go to stable as is.

The old notification had revert button. Looks like regression in new notification UI.

I don't think notification should be used for this, especially with the new paradigm. Notification is not a way to handle critical hardware/UI settings.

This code is already in stable, unless there's a recent regression in the notification code.
sky@ Looking at your screenshot, whenever there is a count down timer like this, there *should* be two buttons "Accept" and "Reject" [1]

I'm surprised you have no buttons. Adding +yoshiki from message_center.

[1]: https://cs.chromium.org/chromium/src/ash/display/resolution_notification_controller.cc?q=ResolutionNotificationController::CreateOrUpdateNotification&sq=package:chromium&l=228-238.

yoshiki@ can you please look into this and verify its a regresssion.
sgabriel@ let's chat about the new paradigm so that i better understand the scope

cheers,
Olga

> sky@ Looking at your screenshot, whenever there is a count down timer like this, there *should* be two buttons "Accept" and "Reject" [1]

The screenshot is how the notification is shown. Only when I interact with some parts of the dialog (not all, just some) do I get the accept/reject buttons.

Scott confirmed that this was tip of tree build - local dev build:
851c021e01671de4dce737ddf65efa225e4f3a98

#13 buttons are automatically hidden in the new design except for the latest notification (change incoming). It works like Android notification system, you need to expand it to see bottom controls.

It looks like no one can reproduce it, could it be that it was a flaky ToT build?

> buttons are automatically hidden in the new design except for the latest notification (change incoming)

Is this indicating the screenshot I attached is intentional? No buttons by default?

Currently it's intentional. Notifications with button(s) are now expandable, and the collapsed version is default. You can expand the notification and see the buttons.

I think we can change the default state from "shrieked" to "expanded". We did simmer hack for SMS sync notificaiton: b/63456632.

Sebastien, could you talk with ovanieva@ and find a good UX? Thanks.

We'll circle back on UX which will most likely be removing this notification entirely. 
I'm not understanding how it cannot be repro, did the count-down feature suddenly disappeared?

The notification will have a button only if you changed the resolution on external display, because there is no guarantee that it will work. If there is
internal display used, we only show "revert", as a user still have a working display. If there is no external display, we set the timer so that it can restore automatically even if the display is completely blank.

With new scaling using dsf coming (63 or 64), we will no longer need a revert nor accept button on these notifications. (and notification shouldn't be shown if it's set from settings, which seems to be regressed. I'll file a bug)

For advanced, physical resolution change option, we'll need a new UI to revert/accept, but it should be rare case.

Yoshiki@ - is the countdown intentional as well? 

sgabriel@ - are you targeting current release with updated UX? or like we discussed later?

Thanks for the details. I thought it was for the primary screen.
re #21, I see a few options:

- Don't ship new notifications until this is fixed (among with the other ones we might have missed)
- Create new UX and implementation for 61, which seems unrealistic

#19, we used to show it only when shortcut is used (otherwise you can't tell the resolution). I filed  crbug.com/757874 .

I think Yoshiki's fix is landed?

https://chromium-review.googlesource.com/c/chromium/src/+/644973

Yes, I did.