1631239 - endless loop with a nested Unfiled Bookmarks shortcut

Status: NEW

(Firefox :: Bookmarks & History, defect, P2)

Description

User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:75.0) Gecko/20100101 Firefox/75.0

Steps to reproduce:

Just to analyze a bit my filed (bug 1625883) I tried to reorganize my Bookmarks, to have a simpler situation for investigation. So I tried to move complete bookmark trees...
How to move them (as I thought) ? Mark entries and do Drag 'n Drop. So I tried to mark an entry. Just clicking on it woun't mark. Firefox jumps to the page behind the bookmark. OK, being more experienced now, I click on a folder as a starting point. Then the folder opens - so far - ok. I click again and the folder closes. ok.
Now it is marked. Holding now down the <Shift>-Key and moving down with the cursor keys marks bookmarks. After having selected all I go to the mouse and try to move the complete bunch of bookmarks to a non-marked bookmark-folder and let it drop. That's what I WANTED to do ...

Actual results:

After marking the bookmarks with the cursor keys, I tryed to move them by mouse. Bam. Firefox goes to sleep. Endless loop.

Expected results:

Moving of bookmarks as normal with moving desktop items. Letting them drop somwhere (at least in the bookmark list) moves them to the new location.

Comment 1

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

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 2

[Mark Banner (:standard8)]

Please could you do a few things for us:

• Go to the three-bar menu -> Help -> Troubleshooting Information
• Scroll down the page to find the "Places Database" section (it is near the bottom).
• Click the "Verify Integrity" button, this may take a few seconds to run.
• Copy and paste the output of the verify integrity section into an attachment on this bug.

Additionally, what was the construction of the bookmarks you selected? Was it just a few bookmarks, or was it a lot of bookmarks nested across multiple folders?

How long did you wait for Firefox to complete?

If possible, please can you attach a screencast of the issue?

Comment 3

[Hardbreaker]

"Verify Integrity" output:

Task: checkIntegrity

• The places.sqlite database is sane
• The favicons.sqlite database is sane

Task: invalidateCaches

• The caches have been invalidated

Task: checkCoherence

• The database is coherent

Task: expire

• Database cleaned up

Task: originFrecencyStats

• Recalculated origin frecency stats

Task: vacuum

• Initial database size is 5120KiB
• The database has been vacuumed
• Final database size is 5120KiB

Task: stats

• Places.sqlite size is 5120KiB
• Favicons.sqlite size is 3680KiB
• pragma_user_version is 53
• pragma_page_size is 32768
• pragma_cache_size is -2048
• pragma_journal_mode is wal
• pragma_synchronous is 1
• History can store a maximum of 57826 unique pages
• Table moz_places has 3524 records
• Table moz_historyvisits has 2245 records
• Table moz_inputhistory has 4 records
• Table moz_hosts has 0 records
• Table moz_bookmarks has 4153 records
• Table moz_keywords has 2 records
• Table sqlite_sequence has 1 records
• Table moz_anno_attributes has 2 records
• Table moz_annos has 36 records
• Table moz_items_annos has 0 records
• Table sqlite_stat1 has 17 records
• Table moz_bookmarks_deleted has 0 records
• Table moz_meta has 7 records
• Table moz_origins has 1478 records
• Index sqlite_autoindex_moz_inputhistory_1
• Index sqlite_autoindex_moz_hosts_1
• Index sqlite_autoindex_moz_keywords_1
• Index sqlite_autoindex_moz_anno_attributes_1
• Index sqlite_autoindex_moz_bookmarks_deleted_1
• Index sqlite_autoindex_moz_origins_1
• Index moz_places_hostindex
• Index moz_places_visitcount
• Index moz_places_frecencyindex
• Index moz_places_lastvisitdateindex
• Index moz_historyvisits_placedateindex
• Index moz_historyvisits_fromindex
• Index moz_historyvisits_dateindex
• Index moz_bookmarks_itemindex
• Index moz_bookmarks_parentindex
• Index moz_bookmarks_itemlastmodifiedindex
• Index moz_places_url_hashindex
• Index moz_places_guid_uniqueindex
• Index moz_bookmarks_guid_uniqueindex
• Index moz_annos_placeattributeindex
• Index moz_items_annos_itemattributeindex
• Index moz_keywords_placepostdata_uniqueindex
• Index moz_bookmarks_dateaddedindex
• Index moz_places_originidindex

Task: _refreshUI

Comment 4

[Hardbreaker]

I have found an anker:
The (sorry German): "Weitere Lesezeichen" - "Additional Bookmarks" is available multiple times. If you try to move ONE of the occurrences you immediately get this error. That's not all but at least one occurrence of this errors.

Comment 5

[Hardbreaker]

Attachment: firefox-endless nested bookmarks.png

New addition: Presumably due to a previos error it seems that I have NOW a kond of endless bookmark list leading to the crash maybe. Please see picture.
How can I get rid of it without loosing my bookmarks ? Thanks.

Comment 6

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

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

For more information, please visit auto_nag documentation.

Comment 7

[Marco Bonardo [:mak]]

The endless hierarchy is "ok", just removing the first duplicate will solve the problem, those are just symlinks/shortcuts to the original folder.
This should not cause hangs though, we should never try to walk a shortcut, and if we do that's the bug. It's probably worth doing some code inspection to check.

For you case, just remove the first copy of Weitere Lesezeichen that is inside Weitere Lesezeichen and things should be fine.

Comment 8

[Firefox Bug Husbandry Bot]

Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is P3 (Backlog,) indicating it has been triaged, the bug's Severity is being updated to S3 (normal.)

Comment 10

[Stephen A Pohl [:spohl]]

As of macOS 26 Tahoe (beta), Spotlight search has started to index menu items in order to make them available as search results. Since bookmarks appear as menu items in the menu bar, an endless loop of bookmark folders as described in this bug will result in a hang of Firefox if Spotlight search is opened when Firefox was active.

Is there anything that we can do on our end to prevent these types of infinite loops of bookmark folders?

I am also filing this bug with Apple.

Comment 11

[Markus Stange [:mstange]]

I second this; having an infinite-depth hierarchy in a menu is not something that seems very desirable from the user's perspective either. We can add a depth limit on the widget side but I think it should also be prevented at the front-end side.

Comment 12

[Marco Bonardo [:mak]]

(In reply to Stephen A Pohl [:spohl] from comment #10)

Is there anything that we can do on our end to prevent these types of infinite loops of bookmark folders?

We can try but likely it will be a performance cost. A bookmark can be moved across views having different characteristics. It can be a folder or a symlink. We should, per each container, examine its parents and its children, that are not always available and often skipped for performance reasons. That is quite a bit of additional I/O. And it must be recursive. It may be fine for a couple bookmarks, but moving hundreds or thousands will be expensive. And we have users with 100k bookmarks with deep nesting.
I don't think doing the check at the time of creation is feasible, if not for some very simple cases.

Alternatively we could add a maintenance task (runs once a week) to detect these cycles... though until it runs the issue would still be there.

Or maybe it should be a mix of the two approaches...
Though this doesn't look like a trivial task.

Comment 13

[Marco Bonardo [:mak]]

For the specific cases of menus, we do have parents always available (As a menu is opened from a parent menu), so we could at the time of opening, disallow opening a sub menu that is also a parent.

Comment 14

[Haik Aftandilian [:haik]]

Hi @mak, with the new macOS Tahoe tripping over this issue, this may warrant being an S2 because it is causing full browsing hangs. Sounds like a tough problem, but if there was something we could do to mitigate it, it could be macOS Tahoe-specific for now. Many people might just find Firefox doesn't work on Tahoe and move to another browser. Perhaps an idle task after startup could be used? For the people with a huge number of bookmarks, a one-time slow down is better than frequent hangs.

Comment 15

[Marco Bonardo [:mak]]

I think I replied in comment 13.
We can surely implement a cleanup task, and we'll do in the future, but it would run delayed (once a week or less) and won't save the user from a crash/hang.
Thus, I don't think it's a good solution.

Instead what we could do is when in the Places menu code we hit a symlink to a folder, we check ancestor menus. If it is linking to a folder that is also an ancestor, we just skip it. There are certainly better visual solutions but supposing in the future we implement the cleanup task, those will be removed anyway, so not rendering them should be fine.

Comment 16

[jeff]

I ran into this after updating last night on dev edition, can confirm that cleaning up a bunch of very old bookmarks seems to have fixed it in dev edition. Couldn't repo easily in nightly because it was a blank profile with no bookmarks. Thanks!