1856891 - Places doesn't properly handle the case-insensitivity of `file:///` URIs on Windows

Status: NEW

(Toolkit :: Places, defect, P3)

Description

[lamalbrut]

Hello. Issue occurs on Windows (edition 11 tested), not on Linux, at least.

Test suggestion:

1. Create a bookmark for the file:///c:/ URI; that will be the unique bookmark for this URI.
2. Edit the bookmark so the URI becomes file:///C:/; note that the characters are unchanged, only the case of a character is modified.
3. Save it.
4. Inspect the bookmark.

Observations:

• The original URI is present instead of the one modified.
• While Bookmarks is selected in about:preferences#privacy at section Address bar, (When using the address bar, suggest), writing "file" in the address bar triggers accordingly two items of file:///c:/ instead of one. Note: this observation is not consistent.

Comment 1

[:Gijs (he/him)]

On Windows, filenames are case insensitive, so this does not seem like a bug to me?

Comment 2

[lamalbrut]

Case insensitive are indeed file names on Windows. Yet how could this detail be a criterion for evaluating the phenomenon exposed in my report? For what it appears, case sensitive are file names as part of the file: URI in Firefox for the creation of unique bookmarks, be their names identical or not. Then for each file:///c:/ and file:///C:/ written in the address bar, will be created a unique bookmark. What makes Firefox for Linux able to save a modification of the case but not Firefox for Windows, is still what remains to be determined.

Comment 3

[:Gijs (he/him)]

(In reply to lamalbrut from comment #2)

Case insensitive are indeed file names on Windows. Yet how could this detail be a criterion for evaluating the phenomenon exposed in my report? For what it appears, case sensitive are file names as part of the file: URI in Firefox for the creation of unique bookmarks, be their names identical or not. Then for each file:///c:/ and file:///C:/ written in the address bar, will be created a unique bookmark.

I don't really follow. For any given URL (file: or otherwise), you can create as many bookmarks as you like - bookmarks are not unique based on the URL they represent.

Comment 0 talks about modifying an existing bookmark. After this, there should still only be 1 bookmark. The way I read your report, your complaint is that when you inspect this 1 bookmark, the URL shows the original case (lowercase 'c' in your example) rather than your "changed" version (uppercase "C" in your example). This probably happens because the two URLs are equivalent (if I had to guess, there's probably some code that checks "is the URL in this field equal to the old URL for this bookmark" before writing to the bookmarks/places DB, and because the two URLs are equal, it doesn't write.). Am I misunderstanding the steps you're taking or the outcomes you're seeing?

The one thing that this report has made me notice, though it isn't mentioned, is that the star in the address bar does not seem to show bookmarks for file URLs (that is, if I go to e.g. file:///C:/Users/, bookmark it, then close the tab and open the same URL, the bookmark star is not filled in). That seems like a bug, but a very different one to what you are reporting.

What makes Firefox for Linux able to save a modification of the case but not Firefox for Windows, is still what remains to be determined.

Filenames are case sensitive on Linux, so file URLs are too, on that platform.

Comment 4

[lamalbrut]

Let us not misinterpret the context of the behavior described in my report; neither Linux nor Windows are involved in what Mozilla's software codes produce, although this is obvious.

As simple as it is, on Firefox for Windows we can

• create two separate bookmarks with the URIs file:///c:/ and file:///C:/, with identical names.
• then modify the URIs of these existing bookmarks by changing their drive letters, e.g. by replacing c and C by d or D; currently replaced by d and D respectively.
• then modify the URIs of these existing bookmarks with the previous modifications by replacing their_d_ and D drive letters respectively by C and c.

What we learned:

• in these circumstances, the URIs file:///c:/ and file:///C:/ can be altered to become file:///C:/ and file:///c:/ respectively.
• in the circumstances exposed in my report, which also concerns Firefox for Windows, the URIs file:///c:/ and file:///C:/ cannot be altered to become file:///C:/ and file:///c:/ respectively.

At last, as a user, or even as a developer, I would ask myself "Does the behavior exposed in my report indicate an issue in Firefox for Windows?".

Comment 5

[Marco Bonardo [:mak]]

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.

Comment 6

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:mak, could you have a look please?

For more information, please visit BugBot documentation.