If the CSV file contains two identical logins, one login is imported and the other one receives the "missing field" error
Categories
(Firefox :: about:logins, defect, P2)
Tracking
()
People
(Reporter: cmuntean, Unassigned)
References
Details
Attachments
(2 files)
[Affected versions]:
- Firefox Nightly 88.0a1 (Build ID:20210301220015);
[Affected Platforms]:
- Windows 10 x64;
- macOS 10.15.7;
- Linux Mint 20 x64;
[Prerequisites]:
- Have the latest Firefox Nightly/Beta installed.
- Have a CSV file with 2 identical logins.
[Steps to reproduce]:
- Open the Firefox browser with the profile from prerequisites.
- Navigate to "about:logins" page.
- Open the menu and click the "Import from a File..." option.
- Select and open the CSV file.
- Click the "View detailed Import Summary" link.
- Observe the import report.
[Expected result]:
- One login is successfully added and the other one is marked as " Duplicate: Exact match of existing login".
[Actual result]:
- One login is successfully added and the other one is recognized as "Missing field" error even if the login is identical with the imported one.
[Notes]:
- Attached a screen recording of the issue.
Comment 1•4 years ago
|
||
I cannot reproduce. Please share the file with me in this bug report.
Maybe LibreOffice is playing pranks with us and slightly changes the format (I saw this in the past with MS Office).
Updated•4 years ago
|
Reporter | ||
Comment 2•4 years ago
|
||
I have attached the CSV file. Let me know if you need any other information.
Comment 3•4 years ago
|
||
Terribly sorry but this is not a bug. Sorry for the confusion.
Duplicate logins without guid => first is added second is duplicated.
Duplicate logins WITH guid => first is added second is error.
Here is the source of the decision.
Any entry with exact matching fields, where modifying the first login with the values
of the second would result in no change is a duplicate. This is also true where we
don't have the information necessary to resolve conflicting values - e.g. 2 different
passwords on an otherwise matching login, with no timestamps to know which
supercedes the other. In these case we leave the first login as-is nd mark the line in
the report for the 2nd login as unchanged so the user can manually update if they
want to.
When there are matching guids within the .csv recordset, this is a strong signal that
this is bad data and something unexpected may happen if we proceed to update
the previous login with this 2nd login's data. This is a very specific failure case, I
guess this is most likely to happen if the same data was concatenated to a .csv file
more than once. I think we should skip importing this line and mark it as an error
in the summary and detailed report.
Reporter | ||
Comment 4•4 years ago
|
||
@Andrei, thank you for clarifying this. I missed the comment with this decision, sorry for that.
Considering this I will close this issue as Resolved - WFM.
Updated•4 years ago
|
Updated•4 years ago
|
Description
•