1925988 - Title in moz_places does not match title for bookmarks in moz_bookmarks even after user have explicitly cleared all history

Status: ASSIGNED

(Toolkit :: Places, defect, P3)

Description

[aoia7rz7l]

Tested on 115.16.1esr and 130.0.1.

(Potential) Prerequisites:

Disable all search-engine-related suggestions.

STR:

1. Create a new bookmark for https://browserleaks.com/ with the title BrowserLeaks - Web Browser Fingerprinting - Browsing Privacy (this was their page title from a few years back).
2. Visit https://browserleaks.com in a new tab.
3. Note that they currently have a different page title, Browserleaks - Check your browser for privacy leaks.
4. Close the tab.
5. Open AppMenu > History > Clear recent history... and clear everything.
6. Type browserleaks.com into the address bar.

Expected Behavior:

Firefox only suggests the browserleaks.com bookmark with the saved title.

Actual Behavior:

Firefox suggests a http://browserleaks.com/ entry with the up-to-date title above the bookmark suggestion, even though the user have explicitly cleared all history.

When I inspected the contents of places.sqlite in the "bad" builds, I noticed that the bookmarked title is stored in moz_bookmarks, but there is another duplicate entry with the up-to-date title in moz_places. The value of fk for the browserleaks.com bookmark in moz_bookmarks also matched value of id for the browserleaks.com entry in moz_places.

Mozregession returned

Last good revision: ba77054848c41f869d9d6a8e1d2c6e02c39dc34a (2023-01-24)
First bad revision: 45cd9ed42ad7f9e8f3b477c99142ec710aa43a09 (2023-01-25)
Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=ba77054848c41f869d9d6a8e1d2c6e02c39dc34a&tochange=45cd9ed42ad7f9e8f3b477c99142ec710aa43a09
Switching bisector method to taskcluster
Getting mozilla-central builds between ba77054848c41f869d9d6a8e1d2c6e02c39dc34a and 45cd9ed42ad7f9e8f3b477c99142ec710aa43a09
...
There are no build artifacts for these changesets (these are probably too old).

I'd say Bug 1791657 but that's just probably what caused the issue to surface in the first place.

Comment 1

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

The Bugbug bot thinks this bug should belong to the 'Firefox Build System::Task Configuration' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Francesco Lodolo [:flod]]

Not sure if this should live in a front-end component, in case please move.

Comment 3

[Marco Bonardo [:mak]]

(In reply to aoia7rz7l from comment #0)

When I inspected the contents of places.sqlite in the "bad" builds, I noticed that the bookmarked title is stored in moz_bookmarks, but there is another duplicate entry with the up-to-date title in moz_places. The value of fk for the browserleaks.com bookmark in moz_bookmarks also matched value of id for the browserleaks.com entry in moz_places.

This was a design decision someone took years ago, I don't like it but we don't have resources to revert it atm.
Doesn't matter anyway, it's the read code that has to cope with it.

I'd say Bug 1791657 but that's just probably what caused the issue to surface in the first place.

Probably it's picking up the history title instead of the bookmark title. Note I am just guessing, didn't actually look at the patch.

Comment 4

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

Set release status flags based on info from the regressing bug 1791657

:daisuke, since you are the author of the regressor, bug 1791657, could you take a look?

For more information, please visit BugBot documentation.

Comment 5

[Daisuke Akatsuka (:daisuke)]

Thank you very much for your report, :aoia7rz7l!
I will take a look at this issue.

Comment 6

[Daisuke Akatsuka (:daisuke)]

Attachment: Bug 1925988: Stop providing result not having history from UrlbarProviderHistoryUrlHeuristic