I'm inclined to mark this a WontFix, as we now deliberately use CTRL+Z to undo deletion of passwords. While I suppose we could change the behavior of CTRL+Z depending on which part of the page has focus, I believe this would be confusing for users. Furthermore, I do believe that undoing a password deletion is more important than undoing the cut of a search query, especially considering that CTRL+V is another suitable workaround.

+maxwalker@ to add feedback from a UX perspective.

Ideally Undo would refer to all previous operations on the passwords page (multiple Undo). For example, if a user first deletes a password and then enters and deletes text in the search field, Undo should first restore the deleted text in the search field and then restore the deleted password. I think this wouldn't be confusing since the outcome of undoing an operation is always visible (for example a restored password reappears in the passwords list).

Interesting observation 1: it seems like clicking the Undo command (in the macOS menu bar) already does restore text in the search field while the keyboard shortcut doesn't. See attached screencast.

Interesting observation 2: the same is true for the global Settings search field which doesn't react to the keyboard shortcut either.

Deleted: Undo.gif 3.0 MB

	Undo.gif 3.0 MB View Download

Yue, PTAL. I think https://crbug.com/778569 can also be related.

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

commit 733deb1b6ea7b21213af40252ed486ce46abf3e5
Author: Yue Cen <rsgingerrs@chromium.org>
Date: Tue Sep 18 00:29:12 2018

Password manager: Ctrl+z command should work on search box.

The expected behavior is that the keyboard event goes first to the
focused editable element. Since it handles the event, the event won't
be processed anymore. If no editable element is focused, the event is
handled by the password handler.

Bug:  862554 
Change-Id: I5286c61891504d410d08004c2caf6055d96ea0af
Reviewed-on: https://chromium-review.googlesource.com/1208820
Reviewed-by: Demetrios Papadopoulos <dpapad@chromium.org>
Reviewed-by: Esmael El-Moslimany <aee@chromium.org>
Commit-Queue: Yue Cen <rsgingerrs@chromium.org>
Cr-Commit-Position: refs/heads/master@{#591895}
[modify] https://crrev.com/733deb1b6ea7b21213af40252ed486ce46abf3e5/chrome/browser/resources/settings/passwords_and_forms_page/BUILD.gn
[modify] https://crrev.com/733deb1b6ea7b21213af40252ed486ce46abf3e5/chrome/browser/resources/settings/passwords_and_forms_page/passwords_section.html
[modify] https://crrev.com/733deb1b6ea7b21213af40252ed486ce46abf3e5/chrome/browser/resources/settings/passwords_and_forms_page/passwords_section.js

Update:

Rechecked the above issue using on latest canary build#71.0.3556.0 on Windows(7,8,8.1.10) ,Linux(14.04 LTS) and Mac(10.12.6 , 10.13.1 , 10.13.6 , 10.14) and issue is fixed.

Please refer attached screencast.

Thank You..

Deleted: Canary Behaviour.mp4 204 KB

	Canary Behaviour.mp4 204 KB View Download

Marked as fixed.