The "saved password were successfully imported" message is wrongly displayed if the "require keychain password" panel is denied when importing passwords from Chrome on Mac OS
Categories
(Firefox :: Migration, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox71 | --- | fix-optional |
People
(Reporter: cmuntean, Unassigned)
References
Details
Attachments
(1 file)
|
4.29 MB,
video/quicktime
|
Details |
[Notes]:
- This might be very confusing for the users since the "Import Wizard" window suggests that the saved password were successfully imported even they are not.
[Affected Versions]:
- Nightly 71.0a1
[Affected Platforms]
- All Mac
[Prerequisites]:
- Have a password set for the OS's account.
- Have multiple saved passwords in Chrome.
[Steps to reproduce]:
- Open the latest Nightly browser and navigate to "about:logins" page and click the "Settings" button.
- Click the "Import Passwords..." option, select Chrome and click the "Continue" button.
- Make sure that only the "Saved Passwords" option is checked and click the "Continue" button.
- Click the "Deny" button from the displayed panel.
- Observe the "Import Wizard".
[Expected results]:
- A message is displayed that informs the user that the passwords were not imported.
[Actual results]:
- The "Import Complete" message is displayed and suggests that the saved passwords were successfully imported.
[Additional Notes]:
- On Windows, this issue is not reproducible since no "require keychain password" panel is displayed.
- Attached a screen recording of the issue.
|
||
Comment 1•5 years ago
|
||
I was aware of this when I implemented bug 1423714 but it's a longstanding issue that I remember discussing with UX a long time ago. At that point since the migrator was the first dialog the user saw, UX didn't want to show any errors or negativity to the user as it could ruin their initial impressions of Firefox. I see now in bug 706008 comment 1 that UX was fine with showing some indication on that final screen (which I didn't remember) so I guess we could do better though it would require string changes at this point.
Considering that this isn't a new issue (the issue applies to all browsers and data types) and a proper fix would involve string changes I don't think this needs to block the addition of Chrome import on macOS in 70.
Description
•