Closed Bug 1695882 Opened 3 years ago Closed 3 years ago

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)

Desktop
All
defect

Tracking

()

RESOLVED WORKSFORME

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]:

  1. Open the Firefox browser with the profile from prerequisites.
  2. Navigate to "about:logins" page.
  3. Open the menu and click the "Import from a File..." option.
  4. Select and open the CSV file.
  5. Click the "View detailed Import Summary" link.
  6. 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.

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).

Flags: needinfo?(cmuntean)
Priority: -- → P2
Attached file logins3.csv

I have attached the CSV file. Let me know if you need any other information.

Flags: needinfo?(cmuntean)

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.

https://bugzilla.mozilla.org/show_bug.cgi?id=1687852#c2

@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.

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WORKSFORME
Blocks: 1649940
No longer blocks: 1650675
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: