After deleting all records from save password the done button is not replaced with edit button, as it is happening in Autofill form. |
||||
Issue descriptionApp Version: 61.0.3163.46 iOS Version: 10.3.3, 9.3.5, 11.0 beta 5 Device: iPhone and iPad Url: rsolomakhin.github.io/autofill Precondition: Save some passwords in the chrome by using the above mentioned url under Name/password Steps to reproduce: 1. Launch chrome 2. Go to Menu>>Settings>>Save passwords 3. Tap on Edit and select all records 4. Tap on delete Observed results: The Done button is still enabled Expected results: Since all records are deleted the done button should be changed to edit, which should be in disabled state. (this behavior is noticed in auto fill form) Number of times you were able to reproduce: 5/5 Bug reproducible after clean install: Yes Bug reproducible after clearing cache and cookies: Yes Bug reproducible on Chrome Mobile on Android: Not tested Bug reproducible on Safari/Firefox: Firefox: NA, Safari: NA Bug reproducible on current stable build (App Version, iOS Version): Yes on M60 Bug reproducible on the current beta channel build (App Version, iOS Version): yes on M61 Link to video/image: https://drive.google.com/a/google.com/file/d/0B8Cek8RsDbF8T25lcE9LQjVsV1E/view?usp=sharing
,
Aug 16 2017
While the behaviour should probably be consistent between password manager and address form autofill, I'm not sure why handling this with the disabled Edit button is preferred to keeping the Done button. Do we have any design docs or mocks for this? (Just for clarification, this is not a regression, and not introduced by the new settings launched in 62.) Given that this is rightly priority 3, and hence can wait, I'm also happy to take it once I'm back, if Vasilii needs his time for more important issues.
,
Aug 16 2017
It's a bug because once you click on Done, the button turns into disabled "Edit". Thus, we prompt user to do a noop. I agree that the priority 3 is appropriate.
,
Nov 16 2017
I might have some time this week while waiting on other blocking tasks. Given that this looks waiting in Vasilii's the queue, I suggest I take it. Vasilii, please do let me know if you disagree.
,
Nov 16 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/7eb7c274db08e9fb1cea558f9f6e9240dc23cf9b commit 7eb7c274db08e9fb1cea558f9f6e9240dc23cf9b Author: Vaclav Brozek <vabr@chromium.org> Date: Thu Nov 16 16:59:12 2017 [iOS] Update Edit button after password deletion Chrome settings on iOS allow selecting a set of saved password entries and deleting them. To select the entries, the view enters the "Edit" mode. If there are any entries left after deletion, the view stays in "Edit", but if there are none, it should go back to the default mode and show a disabled "Edit" button. The code clearly intended to do that, but called |setEdit| by mistake on the view controller instead of on its 'editor' property. This CL fixes that. The CL also fixes the glitch that Edit was not disabled if the last password was deleted from the detailed view. Bug: 755108 Cq-Include-Trybots: master.tryserver.chromium.mac:ios-simulator-cronet;master.tryserver.chromium.mac:ios-simulator-full-configs Change-Id: Ib28679ecf0502f3231ea7d918acd576ce048489e Reviewed-on: https://chromium-review.googlesource.com/774745 Commit-Queue: Vaclav Brozek <vabr@chromium.org> Reviewed-by: Sylvain Defresne <sdefresne@chromium.org> Cr-Commit-Position: refs/heads/master@{#517109} [modify] https://crrev.com/7eb7c274db08e9fb1cea558f9f6e9240dc23cf9b/ios/chrome/browser/ui/settings/passwords_settings_egtest.mm [modify] https://crrev.com/7eb7c274db08e9fb1cea558f9f6e9240dc23cf9b/ios/chrome/browser/ui/settings/save_passwords_collection_view_controller.mm
,
Nov 17 2017
,
Nov 21 2017
Verified on M64.0.3271.0 canary Device: iPhoneX, iOS:11.2 EDIT button is displayed in disabled mode after deleting all of the password entires. |
||||
►
Sign in to add a comment |
||||
Comment 1 by edchin@chromium.org
, Aug 14 2017Owner: vasi...@chromium.org
Status: Assigned (was: Untriaged)