Ahmed this sounds like Chrome's fallback mechanism kicking in when it shouldn't?

Looking into it...

There are two bugs here:

1) In the Display Settings UI: +stevenjb@
    If you have two displays, Display (A) with more modes than Display (B) such that Display (A)'s resolution slider has more ticks than that of Display (B), and the selected mode for Display (A) is >= Display (B)'s number of modes. If Display (A)'s tab is currently selected, and you select Display (B)'s tab, here's an actual example:

- Display (A) has 13 modes with the mode at index 8 is selected. Display (A)'s tab is currently selected.
- Display (B) has 8 modes with the mode at index 3 is selected.
- Switch to Display (B)'s tab. `setSelectedDisplay_()` [1] will attempt to change `this.modeValues_`, which will trigger the slider's `valueChanged_()` changing its tick values, but since the `selectedModePref_.value` hasn't been updated yet, the current slider's index (== 8) is out of range, so it will find the nearest index [2], resulting in the selection of the previous index (== 7), which will effectively change Display (A)'s resolution to the previous value.

I have a CL that fixes this.

2) The other issue is a combination of a UX bug as well as a Notification bug: 
    - The UX bug (+ovanieva@, +sgabriel@): We apply the resolution change only if the user closes the corresponding notification. So if the user makes two successive resolution changes of two different displays, each subsequent resolution change will revert (undo) the previous one (as long as the user doesn't dismiss the notification). This is confusing and unclear. Nothing in the UI indicates to the user that this is the behavior. We need to think of a better design like using a modal dialog or something like what other OSs do.
   
    - The Notifications bug (+tetsui@, +estade@): If the user dismisses the notification by sliding it using touch input, `MessageView::OnSlideOut()` will remove the notification and set the `by_user` bool parameter to `false` [3]. This seems to be a workaround  issue 805208 , and issue 814495. The problem is if `by_user` is `false`, we will not persist the resolution change, and any subsequent changes to different displays will revert the current non-applied one [4].

We can workaround this somehow, but we definitely need a better UX to avoid future problems.


[1]: https://cs.chromium.org/chromium/src/chrome/browser/resources/settings/device_page/display.js?q=setSelectedDisplay_&sq=package:chromium&l=361

[2]: https://cs.chromium.org/chromium/src/chrome/browser/resources/settings/controls/settings_slider.js?q=valueChanged_&sq=package:chromium&l=123

[3]: https://cs.chromium.org/chromium/src/ui/message_center/views/message_view.cc?q=MessageView::OnSlideOut&sq=package:chromium&l=288

[4]: https://cs.chromium.org/chromium/src/ash/display/resolution_notification_controller.cc?q=ResolutionNotificationController::Close&sq=package:chromium&l=166

ah, crud. I wonder how many other notification handlers this breaks. I stopped looking after the first three:

https://cs.chromium.org/chromium/src/chrome/browser/chromeos/hats/hats_notification_controller.cc?rcl=c46d0c69b004fe40d09b25259e9b748c766504f3&l=178
https://cs.chromium.org/chromium/src/ash/system/bluetooth/bluetooth_notification_controller.cc?rcl=c46d0c69b004fe40d09b25259e9b748c766504f3&l=94
https://cs.chromium.org/chromium/src/chrome/browser/chromeos/login/quick_unlock/quick_unlock_notification_controller.cc?rcl=c46d0c69b004fe40d09b25259e9b748c766504f3&l=180

I think we may need to back out our workaround and come up with a better fix for the missing notifications.

I'm having some trouble understanding this issue over a bug, without and extended display to test. Happy to provide UX input if necessary in person. 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/21b13d128cfbfe1c73bd6ba1e71d63841e9944ab

commit 21b13d128cfbfe1c73bd6ba1e71d63841e9944ab
Author: Ahmed Fakhry <afakhry@chromium.org>
Date: Sat Mar 17 01:29:32 2018

MD Settings: Fix a resolution slider bug

Moving from a tab of a display that has more modes to a tab
of another display that has less modes, where the selected
mode of the first display has index >= max index of the second
display's modes, this would result in the first display's mode
changing to the previous one in the slider.

This CL fixes this issue by ignoring change callbacks when the
various parameters of the currently selected display are still
out of sync.

BUG= 822248 

Cq-Include-Trybots: master.tryserver.chromium.linux:closure_compilation
Change-Id: I97d1a55b87ad99d9d6821270618609a7c4a880a7
Reviewed-on: https://chromium-review.googlesource.com/965630
Commit-Queue: Ahmed Fakhry <afakhry@chromium.org>
Reviewed-by: Steven Bennetts <stevenjb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#543903}
[modify] https://crrev.com/21b13d128cfbfe1c73bd6ba1e71d63841e9944ab/chrome/browser/resources/settings/device_page/display.js

 Issue 821129  has been merged into this issue.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/5c8e13b10359ee185b83a616c5f585dbf7f9b764

commit 5c8e13b10359ee185b83a616c5f585dbf7f9b764
Author: Evan Stade <estade@chromium.org>
Date: Wed Mar 21 21:10:11 2018

Partial revert of 5529bc6356b7dcbabea9003673eb2b0a99

Using false for |by_user| for slide out breaks a lot of
NotificationDelegates. We'll have to find another fix.

Bug:  805208 , 822248 
Change-Id: Ic56783427354b96f74ac393b7bcd07380eadfda5
Reviewed-on: https://chromium-review.googlesource.com/966891
Commit-Queue: Evan Stade <estade@chromium.org>
Reviewed-by: Tetsui Ohkubo <tetsui@chromium.org>
Reviewed-by: Ahmed Fakhry <afakhry@chromium.org>
Cr-Commit-Position: refs/heads/master@{#544842}
[modify] https://crrev.com/5c8e13b10359ee185b83a616c5f585dbf7f9b764/ui/message_center/views/message_popup_collection_unittest.cc
[modify] https://crrev.com/5c8e13b10359ee185b83a616c5f585dbf7f9b764/ui/message_center/views/message_view.cc

Is this a duplicate of issue 775757 ?

I forked the remaining UX issue into a separate issue 860097. This one can be closed.