1988315 - Add/Edit bookmark, change storage location: With extensive bookmark collections, the folder list loads extremely slowly.

Status: RESOLVED FIXED

(Firefox for Android :: Bookmarks, defect)

Description

[Denis Müller [:Webworkr]]

User Agent: Mozilla/5.0 (Android 15; Mobile; rv:144.0) Gecko/144.0 Firefox/144.0

Steps to reproduce:

Create a new bookmark or edit an existing one.

Actual results:

As usual, the last used storage location is preselected. If I want to change this storage location, only the “New Folder” option is available. The directory tree of existing folders is not displayed and does not load in the background.

Expected results:

Offers directory tree for selection.

Comment 1

[Denis Müller [:Webworkr]]

144.0a1 (Build #2016113599), 929fad231438df05c484c1635dc5f95614c4b445
GV: 144.0a1-20250909205747
AS: 144.20250909050420
OS: Android 15

Comment 2

[Denis Müller [:Webworkr]]

Hi Jeff,

I am assigning this error a high priority, as it significantly limits the functionality of bookmarks. I therefore request that the unconfirmed bug report be investigated as a matter of priority. Is the bug reproducible? Thank you.

Comment 3

[Jeff Boek [:boek]]

Hey Denis, is there anything showing up in Logcat? I'm not able to reproduce this issue

Comment 4

[Denis Müller [:Webworkr]]

Is there any other way I can access the log, Jeff? I am currently only using my mobile device and therefore cannot use the Android Debug Bridge (ADB) functionality.

Comment 5

[Denis Müller [:Webworkr]]

The phenomenon does not occur in a parallel nightly installation in the work profile.

Unlike the private default profile, no add-ons are currently installed here. However, none of the active extensions should have any influence on bookmarks.

Comment 6

[Denis Müller [:Webworkr]]

Work profile: After logging into my Mozilla account, the phenomenon now occurs here as well.

This suggests that the problem is related to synchronization.

Comment 7

[artella.coding]

I can reproduce this issue, and I believe whether one sees this or not is a function of the number of bookmarks you have.

In a test profile with only handful of bookmarks with sync on, the folder tree shows up immediately but in my full profile when I click edit and try to change the folder, at first all I see is "New folder". If I continue to wait then the folder tree shows up after a couple of minutes.

Note a recent change in Nightly caused this. This was not happening before, and it does not happen in the Firefox release version.

Isnt there timing telemetry in Firefox that can detect this?

Comment 8

[Denis Müller [:Webworkr]]

(In reply to artella.coding from comment #7)

[...] If I continue to wait then the folder tree shows up after a couple of minutes.

I was able to reproduce this observation specifically.

Note a recent change in Nightly caused this. This was not happening before, and it does not happen in the Firefox release version.

I can confirm this for Fennec (F-Droid):

143.0.2 (Build #1430220)
GV: 143.0.2-20250930060036
AS: 143.0
OS: Android 15

However, the phenomenon now also occurs in Beta, where I have tested it again specifically:

144.0b8 (Build #2016117743), b69abb7294b398b1274e777de33a0905da52ecf1
GV: 144.0-20251001090614
AS: 144.0.1
OS: Android 15

Comment 9

[Matt Tighe [:matt-tighe]]

:Webworkr, are you experiencing slowness in the regular bookmarks list, or only in the screen that allows you to select a folder? Bug 1957636 seems like a potential candidate where we are counting the number of child bookmarks for folders. This change would've impacted both screens though.

Comment 10

[Denis Müller [:Webworkr]]

(In reply to Matt Tighe [:matt-tighe] from comment #9)

:Webworkr, are you experiencing slowness in the regular bookmarks list, or only in the screen that allows you to select a folder? Bug 1957636 seems like a potential candidate where we are counting the number of child bookmarks for folders. This change would've impacted both screens though.

Hi Matt,

in my opinion, the regular bookmarks sometimes load a little slower than usual. The estimated duration is perhaps a maximum of 1 second when it takes a really long time. However, this is nothing compared to editing the storage location.

Comment 11

[Denis Müller [:Webworkr]]

Due to the long loading time, I sometimes switch to other apps or to standard mode in the meantime.

When in private mode, the browser occasionally crashes immediately after closing the bookmark menu, after the bookmark has been successfully edited (possibly related to bug 1837010, bug 1993074).

If only the private tabs crash, no crash reports are currently written (bug 1913616).

Comment 12

[Denis Müller [:Webworkr]]

For the sake of completeness, it should be mentioned that this phenomenon also occurs when creating and moving a bookmark folder.

In my opinion, this is likely to have the same cause.

Comment 13

[Denis Müller [:Webworkr]]

The problem has now also appeared in the release version and is therefore likely to affect a larger number of users.

Fennec (F-Droid)

144.0.0 (Build #1440020)
GV: 144.0-20251022155017
AS: 144.0.1
OS: Android 15

Comment 14

[Denis Müller [:Webworkr]]

Is there any chance that this issue will be resolved soon?
The long loading times are quite annoying.

Comment 15

[Denis Müller [:Webworkr]]

In a specific scenario when creating a new folder, there is no increase in loading time. However, I have only observed this once.

“Need info” request for further investigation.

Comment 16

[Jan Zerebecki]

I also have this problem with a profile that has more than 10k, less than 100k bookmarks. I currently don't have the spare hardware to do Android remote profiling and trying to make a profile run that does not contain as much of my private data would probably take too much time. I tried directly profiling ( as in https://github.com/firefox-devtools/profiler/blob/main/docs-user/guide-profiling-android-directly-on-device.md start profile, edit bookmark, click the folder chooser, wait 12s until it shows, go back to edit bookmark, stop profile via notification). But I failed to get something useful from the profile. I can find things from https://searchfox.org/firefox-main/source/mobile/android/fenix/app/src/main/java/org/mozilla/fenix/bookmarks/BookmarksScreen.kt in it. But I can not find an obvious place where it takes so long. This is a build from F-droid, so it doesn't have symbols resolved, but that might not matter as it still shows resolved symbols in JVM, the rest is mostly the same one libc function in all other threads (probably waiting in kernel).

It takes many seconds to display the bookmark folder list, the profiling recorded for 60s due to time the human interacted. But afterwards repeating the action and counting in my head, it took 12s for the bookmark folder list to display. It spends 900ms and 211 samples in android.os.Handler.dispatchMessage or in terms of only selecting the time range that is likely relevant 200ms and 52 samples (which already is much less than 12s and anything else seems less involved in the problem), but when the stack gets to e.g. the first function that is not Android system code, which is org.mozilla.fenix.bookmarks.BookmarksScreenKt$SelectFolderScreen$lambda$6$0$0$$inlined$items$default$4.invoke , that is one sample of 4ms. Android UI spending 900ms of 60s on everything besides the problem seem realistic. No idea if it is my unfamiliarity or the time is just not directly visible in the profiling data. Maybe if there was a profiling view that shows time taken for events across wait time instead of cpu time in functions it would be obvious.

Anyway it should be straight forward to reproduce with 100k bookmarks.

Comment 17

[Jeff Boek [:boek]]

I understand the pain of the current implementation and I'm working on getting a fix prioritized.

Comment 18

[Matt Tighe [:matt-tighe]]

This is likely because of the full recursive search we are doing here. Compare this to the bookmarks list screen, where we are able to just get a recursive count.

The SQL query that defines the full tree recursion is here while the count is defined here. Perhaps there's something in the middle we can do to get a faster full-depth recursion that only has the folder titles we need for the folder selection screen?

Comment 19

[Jeff Boek [:boek]]

I think that we can do two things in the immediate that will solve this issue:

1. Let's present a loading state so a user will know that something is happening and it doesn't look like the only option is to add a new folder
2. Instead of loading the entire tree at once we should handle this similar to desktop where we only load the root and a user can choose what to expand and load into memory.

Comment 20

[Mark Hammond [:markh] [:mhammond]]

bookmarksStorage.getTree(BookmarkRoot.Root.id, recursive = true) should never be used. I wonder if the underlying API should throw in that scenario? There's even an argument that even just "recursive = true` shouldn't be used. As implied above, the intent would be that you just fetch one level at a time and expand based on user-input (ie, when they select a folder)

Comment 21

[artella.coding]

Instead of loading the entire tree at once we should handle this similar to desktop where we only load the root and a user can choose what to expand and load into memory

The following might be relevant to this :

in modify bookmark folder the list of folders is always expanded

and :

Bookmarks folder navigation in edit mode : allow Flat Navigation Folder Contents View like Chrome for Android rather than expanded tree Or alternatively Allow Cut and Paste in Browsing mode

Comment 22

[Denis Müller [:Webworkr]]

(In reply to Denis Müller [:Webworkr] from comment #15)

In a specific scenario when creating a new folder, there is no increase in loading time. However, I have only observed this once.

“Need info” request for further investigation.

I have now been able to reproduce the scenario and hope that I am describing it correctly.

1. Save or change a bookmark.
2. Change the storage location.
3. Now there are long loading times for the folder list.
4. Select the destination folder.
5. Then select “New Folder.”
6. Change the storage location of the new folder.
7. There are now NO increased loading times when loading the folder list.
8. Select the destination folder.
9. Finish editing.

Comment 23

[Denis Müller [:Webworkr]]

(In reply to artella.coding from comment #21)

Instead of loading the entire tree at once we should handle this similar to desktop where we only load the root and a user can choose what to expand and load into memory

The following might be relevant to this :

in modify bookmark folder the list of folders is always expanded

and :

Bookmarks folder navigation in edit mode : allow Flat Navigation Folder Contents View like Chrome for Android rather than expanded tree Or alternatively Allow Cut and Paste in Browsing mode

I agree with Jeff's suggestions. In this context, I would like to add bug 1902129, “Add/edit bookmarks: Tree view (with expandable and collapsible subfolders)”. The suggested improvement is along the same lines as the previous speaker's.

Point 2 from Jeff would also eliminate the need to scroll through long folder lists. This can be particularly annoying on a cell phone.

Comment 24

[Denis Müller [:Webworkr]]

While moving two bookmarks simultaneously (in private mode), the browser crashed completely (again).

Comment 25

[Matt Tighe [:matt-tighe]]

Attachment: Bug 1988315 - convert select screen to use expandable chevrons and load bookmarks lazily

Comment 26

[Denis Müller [:Webworkr]]

(In reply to Jeff Boek [:boek] from comment #19)

I think that we can do two things in the immediate that will solve this issue:

1. Let's present a loading state so a user will know that something is happening and it doesn't look like the only option is to add a new folder

In the meantime published:

148.0a1 (Build #2016133279), d7927d5dcb2cb6f8d89b49407e2515d8429bf33c
GV: 148.0a1-20251221084633
AS: 148.20251217050246
OS: Android 15

Comment 27

[Denis Müller [:Webworkr]]

(In reply to Denis Müller [:Webworkr] from comment #26)

(In reply to Jeff Boek [:boek] from comment #19)

I think that we can do two things in the immediate that will solve this issue:

1. Let's present a loading state so a user will know that something is happening and it doesn't look like the only option is to add a new folder

In the meantime published:

148.0a1 (Build #2016133279), d7927d5dcb2cb6f8d89b49407e2515d8429bf33c
GV: 148.0a1-20251221084633
AS: 148.20251217050246
OS: Android 15

If the tab or app is completely in the background for a longer period of time while the folder list is loading, the loading status indicator occasionally disappears.

If the user then switches to the “←” button at the top left of the browser, possibly due to irritation, the screen turns completely black, with no menu items or buttons accessible. (I need to verify this point again.)

Comment 28

[Denis Müller [:Webworkr]]

(In reply to Denis Müller [:Webworkr] from comment #27)

(In reply to Denis Müller [:Webworkr] from comment #26)

(In reply to Jeff Boek [:boek] from comment #19)

I think that we can do two things in the immediate that will solve this issue:

1. Let's present a loading state so a user will know that something is happening and it doesn't look like the only option is to add a new folder

In the meantime published:

148.0a1 (Build #2016133279), d7927d5dcb2cb6f8d89b49407e2515d8429bf33c
GV: 148.0a1-20251221084633
AS: 148.20251217050246
OS: Android 15

If the tab or app is completely in the background for a longer period of time while the folder list is loading, the loading status indicator occasionally disappears.

If the user then switches to the “←” button at the top left of the browser, possibly due to irritation, the screen turns completely black, with no menu items or buttons accessible. (I need to verify this point again.)

The last point mentioned (“←”) occurs frequently, but apparently not always.

Comment 29

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/868e65dcf9ea
https://hg.mozilla.org/integration/autoland/rev/95f3b8d51449
convert select screen to use expandable chevrons and load bookmarks lazily r=android-reviewers,boek,android-l10n-reviewers,flod

Comment 30

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/95f3b8d51449

Comment 32

[Denis Müller [:Webworkr]]

The code change has now arrived in the Nightly channel.

148.0a1 (Build #2016137015), 13aa00007318ba9e4ef01df74e6157e705c35b55
GV: 148.0a1-20260109202627
AS: 148.20260109050201
OS: Android 15

Comment 33

[Denis Müller [:Webworkr]]

I have > 50k bookmarks.

The change is a significant improvement over the previous version. However, there are still areas for improvement.

1. Opening a folder sometimes takes a while. It seems like the browser isn't responding. Please check again to see if the performance can be optimized. If necessary, bring back the loading indicator.
2. The selected sorting algorithm doesn't work when choosing the destination folder. In my case, the sorting order is set to A-Z.

Comment 34

[Denis Müller [:Webworkr]]

I also noticed today that when selecting the storage location, the actual folder structure is not fully displayed. Screenshots will follow.

Comment 35

[Denis Müller [:Webworkr]]

Attachment: Screenshot_20260112-174000.Firefox Nightly.png

First folder level (my current personal folder structure)

Comment 36

[Denis Müller [:Webworkr]]

Attachment: Screenshot_20260112-174155.Firefox Nightly.png

Reduced first folder level when selecting the storage location

Comment 37

[Denis Müller [:Webworkr]]

(In reply to Denis Müller [:Webworkr] from comment #33)
...

1. Opening a folder sometimes takes a while. It seems like the browser isn't responding. Please check again to see if the performance can be optimized. If necessary, bring back the loading indicator.

See also Bug 2009006.

Comment 38

[Matt Tighe [:matt-tighe]]

Hello again! I'm going to re-close this bug as I think we have addressed the most pressing functionality. We will continue to track Bug 2009006 to add a loading indicator.

The behavior you've indicated in your other comments does seem like a potential enhancement. Technically, the "first" folder level you are used to seeing is actually a subfolder of a bookmarks root that is more accurately displayed in the "reduced" first folder level shown in your second screenshot. We do some manipulation to get a mobile-first view of the tree on the bookmark list screen.

Since we are now loading the tree one piece at a time, it makes sense that only the true root is displayed at first on the select folder screen. You can see your expected "first" folder level by expanding the items there. If you think that is a behavior worth changing, would you mind filing a separate bug? It may require some product or UX input

Comment 39

[Denis Müller [:Webworkr]]

(In reply to Denis Müller [:Webworkr] from comment #33)

2. The selected sorting algorithm doesn't work when choosing the destination folder. In my case, the sorting order is set to A-Z.

I have now reported this in Bug 2009935.

Comment 40

[Denis Müller [:Webworkr]]

(In reply to Matt Tighe [:matt-tighe] from comment #38)

[…]
The behavior you've indicated in your other comments does seem like a potential enhancement. Technically, the "first" folder level you are used to seeing is actually a subfolder of a bookmarks root that is more accurately displayed in the "reduced" first folder level shown in your second screenshot. We do some manipulation to get a mobile-first view of the tree on the bookmark list screen.

I am aware of that. I didn't express myself clearly enough. I should have referred to the first folder level below the root directory.

Since we are now loading the tree one piece at a time, it makes sense that only the true root is displayed at first on the select folder screen. You can see your expected "first" folder level by expanding the items there. If you think that is a behavior worth changing, would you mind filing a separate bug? It may require some product or UX input

According to tests conducted so far, the root directory cannot be expanded. This means that parallel folders at the desktop level are no longer accessible as possible storage destinations.

I also miss the system folder “mobile bookmarks,” especially on a mobile device.

I have opened 2009951 as a follow-up. In this context, I believe that referring to this as “only” an improvement does not do it justice. I have therefore declared the follow-up ticket as a bug.

Comment 41

[Denis Müller [:Webworkr]]

(In reply to Denis Müller [:Webworkr] from comment #11)

Due to the long loading time, I sometimes switch to other apps or to standard mode in the meantime.

When in private mode, the browser occasionally crashes immediately after closing the bookmark menu, after the bookmark has been successfully edited (possibly related to bug 1837010, bug 1993074).

If only the private tabs crash, no crash reports are currently written (bug 1913616).

→ Bug 2011047 (Crash when adding/editing bookmarks, change storage location.)