Open Bug 1988315 Opened 2 months ago Updated 1 day ago

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

Categories

(Firefox for Android :: Bookmarks, defect)

Product:
Firefox for Android
Component:
Bookmarks
Version:
Firefox 144
Platform:
All
Android
Type:
defect

Tracking

()

Status:
UNCONFIRMED

People

(Reporter: Webworkr, Unassigned, NeedInfo)

References

Details

(Keywords: crash, Whiteboard: [fxdroid][group1])

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.

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

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.

Flags: needinfo?(jboek)

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

Flags: needinfo?(jboek)
Flags: needinfo?(c52w1h6sv)

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.

Flags: needinfo?(c52w1h6sv) → needinfo?(jboek)

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.

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

This suggests that the problem is related to synchronization.

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?

Severity: -- → S3
Flags: needinfo?(jboek)
Whiteboard: [fxdroid][group1]

(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
See Also: → 1992454
Summary: Add/edit bookmarks: Only a new folder can be selected as the storage location. → Add/Edit bookmark, change storage location: With extensive bookmark collections, the folder list loads extremely slowly.

: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.

(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.

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).

Keywords: crash
See Also: → 1837010, 1993074, 1913616

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.

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

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

Flags: needinfo?(jboek)

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.

Flags: needinfo?(c52w1h6sv)

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.

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

Flags: needinfo?(jboek)

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?

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.

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)

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

You need to log in before you can comment on or make changes to this bug.