Bugzilla

This is because they effectively represent the same URI at the URL parser level `new URL("file:///C:/").URI.equals(new URL("file:///c:/").URI)` and we bailout here https://searchfox.org/mozilla-central/rev/d436104fc6c31677b08a851796bead25153be699/browser/components/places/content/editBookmark.js#798

Rather than this bug, that in itself is innocuous, it's probably more interesting to notice Places handles uris as strings at the database level, so while we should ideally not end up with multiple entries, we actually do. Considered the low amount of file:/// URIs I don't think it's a big concern from a space point of view.
From a features point of view, I can think to a couple things that won't work as expected:
1. tagging one of these uris won't tag all of them. Again I don't think it's particularly common to tag file:// URIs and end up with different casing
2. visited link coloring is likely wrong

The problem is we're optimized around strings, so fixing this may cause a performance hit on URIs matching. We could calculate our url hashes on a lowercased string in these cases, and then do additional comparison using a SQL function that is aware of the platform and protocol.

This is because they effectively represent the same URI at the URL parser level `new URL("file:///C:/").URI.equals(new URL("file:///c:/").URI)` and we bailout here https://searchfox.org/mozilla-central/rev/d436104fc6c31677b08a851796bead25153be699/browser/components/places/content/editBookmark.js#798

Rather than this bug, that in itself is innocuous, it's probably more interesting to notice Places handles uris as strings at the database level, so while we should ideally not end up with multiple entries, we actually do. Considered the low amount of file:/// URIs I don't think it's a big concern from a space point of view.
From a features point of view, I can think to a couple things that won't work as expected:
1. tagging one of these uris won't tag all of them. Again I don't think it's particularly common to tag file:// URIs and end up with different casing
2. visited link coloring is wrong, and it works correctly in other browsers

The problem is we're optimized around strings, so fixing this may cause a performance hit on URIs matching. We could calculate our url hashes on a lowercased string in these cases, and then do additional comparison using a SQL function that is aware of the platform and protocol.