Another loss of focus issue to tackle along with this one: after a user adds, edits or deletes a shortcut we should move focus to the "Undo" portio of the messaging UI that communicates what the user did. 

An addition to c3: and then (after the messaging UI goes away) ideally focus would move to the next shortcut instead of being lost.

So, the expected behavior is:
(1) After a user adds, edits or deletes a shortcut, the focus should move to "Undo" button in the message bar. (That is doable)
(2) After the message bar goes away, the focus will move to next shortcut. (What will be the next shortcut?)

With response to comment #7 :

After dismissing the 'Add shortcut' overlay focus should be seen on 'Add shortcut' thumbnail.

+Yana: What do you think regarding Weilun's question (2) in #7? Options:
1. No focus
2. Add Shortcut 
3. Omnibox (default for a newly opened NTP)

Moving focus to Add shortcut SGTM.

So to recap: After a user adds, edits or deletes a shortcut, the focus should move to "Undo" button in the message bar. Then, after the message bar is dismissed or goes away on its own, we should move the focus to "Add shortcut".

However, please note that in line with c8, if a user dismisses the edit dialogue without saving, we should keep the focus on either the associated link or the three-dot menu for the dialogue that was just dismissed - whichever is easiest. And if a user dismisses the add dialogue without saving, we should show the focus on the Add shortcut thumbnail.

For what we have discussed during the meeting. If we want to focus on the three dot menu after the cancel button was clicked, there will be a focus ring on the three dot menu even when we use mouse-navigation. Are we sure about this?

Deleted: capture.webm 3.4 MB

	capture.webm 3.4 MB View Download

The second part of c10 has been already done. However, move the focus point to add shortcut tile is not trivial, because hitting undo/restore button on the notification bar will cause that iframe to reload which is the same behavior as the init render. That means if we focus any components on the mv-single iframe, the focus will disappear after reload. 

Update c11 that the focus ring will only appear if you hit enter key on the cancel button, but not for mouse navigation.

@Yana: Weilun's looking for feedback on c#13. It's not trivial to focus on a specific custom link after hiding the notification bar - even if that's the 'Add Shortcut' link (because the mv-single iframe will be reloaded after any change on backend). Does it make sense to split this into two, s.t. the first part can land, or would a different focus area work?

We can definitely land this in two.

Wrt a different focus area, I suppose what we could in that case is focus on the omnibox. It's not ideal but better than losing focus altogether.

@c11: that's ok to me as long as it's for keyboard navs only

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

commit f107e6c78054dca34047d4a029f92b9d3bff7177
Author: Weilun Shi <sweilun@chromium.org>
Date: Wed Sep 05 02:18:04 2018

[NTP] Focus on undo button when notification bar float up

When the custom link tile gets modified(add/edit/delete), focusing on
the undo button on the notification bar. Using tab on undo button can
navigate to restore button as well.

Bug:  873978 ,  865840 
Change-Id: Idf8420d3622e645e8980fc40be5682028daf8638
Reviewed-on: https://chromium-review.googlesource.com/1188492
Reviewed-by: Kristi Park <kristipark@chromium.org>
Commit-Queue: Weilun Shi <sweilun@chromium.org>
Cr-Commit-Position: refs/heads/master@{#588741}
[modify] https://crrev.com/f107e6c78054dca34047d4a029f92b9d3bff7177/chrome/browser/resources/local_ntp/custom_links_edit.js
[modify] https://crrev.com/f107e6c78054dca34047d4a029f92b9d3bff7177/chrome/browser/resources/local_ntp/local_ntp.js
[modify] https://crrev.com/f107e6c78054dca34047d4a029f92b9d3bff7177/chrome/browser/resources/local_ntp/most_visited_single.js

Update:
Rechecked this issue on Windows(7,8,8.1,10), Mac(10.12.6, 10.13.1, 10.13.6, 10.14) and Linux(14.04) machines using latest Canary #71.0.3544.0 and issue is fixed. Hence adding TE-Verified labels.

please refer the attached screen-cast for reference.

Thank you.

Deleted: Fixed behavior.mp4 783 KB

	Fixed behavior.mp4 783 KB View Download

Note: the fix here caused issues so we're modifying it to only refocus on the omnibox if the user explicitly clicks on the Undo or Restore All. See  crbug.com/882335 

Reassigning to add to remote NTP