1949674 - Slow and freezing when searching in the Bookmark Organizer in Firefox 135.x

Status: UNCONFIRMED

(Firefox :: Bookmarks & History, defect)

Description

[oltros]

Steps to reproduce:

Updated Firefox from version 134.0.2 to 135.0.

Actual results:

I am experiencing slowness when searching in the Bookmark Organizer. (CTRL+SHIFT+O) For example, if I type “quake” in the Bookmark Organizer to find bookmarks with “quake” in the name or tag, Firefox freezes for 15 seconds before the search results appear. Prior to this issue, the search results were instantaneous when I typed the search term.

I'm pretty sure this issue started with the update to version 135.0. I didn't have this issue up until version 134.0.2, but as soon as I updated to 135.0, it started happening. I was hoping that 135.0.1 would fix it, but it didn't.

I tried many things, including disabling all add-ons and reinstalling 135.0, but nothing worked.

The only solution was to reinstall 134.0.2, which was the version before 135.0 came out. I copied the places.sqlite file I was using and then searched for my bookmarks in the Bookmark Organizer and they came up immediately, just like before.

I have 121,767 Firefox bookmarks and my places.sqlite file is 145MB (152,043,520 bytes) in size.

My PC specs: (I tested on both PCs)

1. AMD Ryzen 7 7800x3D / DDR5 32GB / WD SN850X 2TB / Windows 11 Home 24H2 (26100.3194)
2. AMD Ryzen 7 5700x3D / DDR4 48GB / SAMSUNG 1TB / Windows 11 Home 22H2 (22621.4317)

Expected results:

Firefox should stop freezing for about 15 seconds when searching in the Bookmark Organizer (CTRL+SHIFT+O) in versions 135.0 and 135.0.1. (I'm going back to 134.0.2 until the issue is resolved).

Comment 1

[Marco Bonardo [:mak]]

Could you please capture a Performance Profile using the Firefox Profiler? See https://profiler.firefox.com/ for instructions on how to do that.

Comment 2

[oltros]

(In reply to Marco Bonardo [:mak] from comment #1)

Could you please capture a Performance Profile using the Firefox Profiler? See https://profiler.firefox.com/ for instructions on how to do that.

https://share.firefox.dev/4bb71Y6

Comment 3

[James Teow [:jteow]]

Marco will investigate to see if there was a change in 135 that could have caused this issue.

Comment 4

[Marco Bonardo [:mak]]

A SQL query is taking a long time, I assume due to tags retrieval. We didn't change anything in 135 around that, but we update SQLite to 3.47.2 and maybe that changes some optimization around this query. I see SQLite 3.49 (that we will use in Firefox 137) has some fixes for the query planner, but I can't tell if it solved the problem. I'll have to build a test database with a meaningful amount of bookmarks and tags to check.

Comment 5

[Marco Bonardo [:mak]]

I created a profile with 160k bookmarks and 100k tags, but searching in the library is still quite fast for me, my specs are more or less aligned with the ones in comment 0 (5800x3D, 32GB ram, ssd Samsung). There must be some additional condition, for which I may need additional statistics for your database. Attaching a txt log from about:support may help as it contains counts of entries per each table.

For now the only thing I can suggest, after a BACKUP OF THE WHOLE PROFILE FOLDER, is to copy your places.sqlite into a new separate profile and try to launch that new profile with Firefox Nightly... if the problem is solved in Nightly, then it's because of the query planner changes in SQLite 3.47 that were addressed in 3.49. Then it's just matter of awaiting for the update.
Otherwise, I will have to find a way to replicate this database contents with dummy data.

Comment 6

[oltros]

(In reply to Marco Bonardo [:mak] from comment #5)

Here is the txt file.

https://pastebin.com/1xxBCpPH

I installed Firefox Nightly 137.0a1 (2025-02-24) (64-bit) and copied my places.sqlite into a new profile. I'm still experiencing slowdowns and freezes with this version.

Comment 7

[Marco Bonardo [:mak]]

It looks like the paste is under moderation. you could also attach it as a file directly in Bugzilla.

Since you have this places.sqlite file in this new profile, you could try to open it with a SQLite editor (e.g. DB Browser for SQLite) and execute a couple commands on it: VACUUM; and PRAGMA optimize;. Then close the app confirming changes, and reopen Firefox with that profile.
Any difference?

I'll also ask, just in case you're comfortable with that, you could send me that file by private mail to my mozilla.com address (using some kind of e2e encrypted service with expiration). It's not a problem if you prefer to avoid sharing your history and bookmarks with me, but it's worth asking, as it's harder to debug remotely.

Comment 8

[oltros]

Attachment: about-support.txt

about:support

Comment 9

[Marco Bonardo [:mak]]

I see between bookmarks and tags you're around 300k entries, not too far away from my test db with 260k, I can likely grow it a little bit more.

Comment 10

[Yazan Al Macki [:yazan]]

Reminder to take a look at this whenever you are able to

Comment 11

[Marco Bonardo [:mak]]

Unfortunately, even with 600k entries (about 1/3 folders, rest is tags and bookmarks) I don't see a difference between 134 and newer versions, nor in the SQLite command line, trying to replicate the slow query.
There is certainly a boundary condition in this specific case that I cannot replicate as I don't know what it is.

At this point I can only suggest to use mozregression with --good 134 --bad 135 --profile=/path/to/profile --profile-persistence clone-first after copying the profile folder to some test path and removing compatibility.ini from it.
That should allow identifying which revision in 135 caused the regression and would help giving us some debugging direction.