After testing STR from bug #1540669 Comment #12 to see if bug is really fixed for sure and later mark it as verified, I encounter very odd issue. I have many bookmarks open, and unfortunately, I opened some more, before closing some of them, and Firefox hangs for some time due to OOM and system started dumping some of memory to swap file on HDD. Before hang I was removing 1 bookmark and readded it when started. When Firefox unhanged itself, I now seeing that I have 3 same bookmarks which I can't delete and after opening this bookmark, Star UI shows it as not bookmarked.

After Verifying Integrity of Places Database in about:support, I get this error:

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

• Unable to vacuum database

Task: stats

• The task queue was cleared by an error in another task.

Task: _refreshUI

• The task queue was cleared by an error in another task.

After trying to delete this 1 of 3 undeletable bookmarks, I get this in Browser Console:

TypeError: "info is null"
removeThem resource://gre/modules/PlacesTransactions.jsm:1340
removeThem resource://gre/modules/PlacesTransactions.jsm:1339
execute resource://gre/modules/PlacesTransactions.jsm:1344
promise resource://gre/modules/PlacesTransactions.jsm:532
promise resource://gre/modules/PlacesTransactions.jsm:458
promise callbackenqueue resource://gre/modules/PlacesTransactions.jsm:458
transact resource://gre/modules/PlacesTransactions.jsm:529
transact resource://gre/modules/PlacesTransactions.jsm:217
batch resource://gre/modules/PlacesTransactions.jsm:318
batch resource://gre/modules/PlacesTransactions.jsm:552
promise resource://gre/modules/PlacesTransactions.jsm:458
promise callbackenqueue resource://gre/modules/PlacesTransactions.jsm:458
batch resource://gre/modules/PlacesTransactions.jsm:547
batch resource://gre/modules/PlacesTransactions.jsm:315
_removeRowsFromBookmarks chrome://browser/content/places/controller.js:826
batchUpdatesForNode resource:///modules/PlacesUIUtils.jsm:872
_removeRowsFromBookmarks chrome://browser/content/places/controller.js:825
remove chrome://browser/content/places/controller.js:898
PC_doCommand chrome://browser/content/places/controller.js:219
goDoCommand chrome://global/content/globalOverlay.js:81
oncommand chrome://browser/content/places/places.xul:1

TypeError: "info is null"
removeThem resource://gre/modules/PlacesTransactions.jsm:1340
removeThem resource://gre/modules/PlacesTransactions.jsm:1339
execute resource://gre/modules/PlacesTransactions.jsm:1344
promise resource://gre/modules/PlacesTransactions.jsm:532
promise resource://gre/modules/PlacesTransactions.jsm:458
promise callbackenqueue resource://gre/modules/PlacesTransactions.jsm:458
transact resource://gre/modules/PlacesTransactions.jsm:529
transact resource://gre/modules/PlacesTransactions.jsm:217
batch resource://gre/modules/PlacesTransactions.jsm:318
batch resource://gre/modules/PlacesTransactions.jsm:552
promise resource://gre/modules/PlacesTransactions.jsm:458
promise callbackenqueue resource://gre/modules/PlacesTransactions.jsm:458
batch resource://gre/modules/PlacesTransactions.jsm:547
batch resource://gre/modules/PlacesTransactions.jsm:315
_removeRowsFromBookmarks chrome://browser/content/places/controller.js:826
batchUpdatesForNode resource:///modules/PlacesUIUtils.jsm:872
_removeRowsFromBookmarks chrome://browser/content/places/controller.js:825
remove chrome://browser/content/places/controller.js:898
PC_doCommand chrome://browser/content/places/controller.js:219
goDoCommand chrome://global/content/globalOverlay.js:81
oncommand chrome://browser/content/places/places.xul:1
PlacesTransactions.jsm:320:21
TypeError: "info is null"
removeThem resource://gre/modules/PlacesTransactions.jsm:1340
removeThem resource://gre/modules/PlacesTransactions.jsm:1339
execute resource://gre/modules/PlacesTransactions.jsm:1344
promise resource://gre/modules/PlacesTransactions.jsm:532
promise resource://gre/modules/PlacesTransactions.jsm:458
promise callbackenqueue resource://gre/modules/PlacesTransactions.jsm:458
transact resource://gre/modules/PlacesTransactions.jsm:529
transact resource://gre/modules/PlacesTransactions.jsm:217
batch resource://gre/modules/PlacesTransactions.jsm:318
batch resource://gre/modules/PlacesTransactions.jsm:552
promise resource://gre/modules/PlacesTransactions.jsm:458
promise callbackenqueue resource://gre/modules/PlacesTransactions.jsm:458
batch resource://gre/modules/PlacesTransactions.jsm:547
batch resource://gre/modules/PlacesTransactions.jsm:315
_removeRowsFromBookmarks chrome://browser/content/places/controller.js:826
batchUpdatesForNode resource:///modules/PlacesUIUtils.jsm:872
_removeRowsFromBookmarks chrome://browser/content/places/controller.js:825
remove chrome://browser/content/places/controller.js:898
PC_doCommand chrome://browser/content/places/controller.js:219
goDoCommand chrome://global/content/globalOverlay.js:81
oncommand chrome://browser/content/places/places.xul:1

I will report back later, if I can delete them after Firefox restart.

:Virtual, if you think that's a regression, then could you try to find a regression range in using for example mozregression?

I want to add that after playing, still some moved and newly added bookmarks are placed in incorrect and wrong order in folder in Library.

(In reply to Virtual_ManPL [:Virtual] - (please needinfo? me - so I will see your comment/reply/question/etc.) from comment #0)

I will report back later, if I can delete them after Firefox restart.

Fortunately, it fixed itself,
but unfortunately, I lost all these removed and readded bookmarks, history from this time is also missing.
Thankfully, I have backup of them, so they were restored.

I suspect that it's regression from bug #1540669, as I didn't encounter this issue before.

I forgot to add that these 3 duplicated undeletable bookmarks were also missing.

I'm also attaching Verifying Integrity of Places Database in about:support after restart:

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 76800KiB
• The database has been vacuumed
• Final database size is 71680KiB

Task: stats

• Places.sqlite size is 71680KiB
• Favicons.sqlite size is 58144KiB
• 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 132396 unique pages
• Table moz_places has 126146 records
• Table moz_historyvisits has 73690 records
• Table moz_inputhistory has 0 records
• Table moz_hosts has 0 records
• Table moz_bookmarks has 85570 records
• Table moz_bookmarks_deleted has 5 records
• Table moz_keywords has 0 records
• Table sqlite_sequence has 1 records
• Table moz_anno_attributes has 3 records
• Table moz_annos has 46037 records
• Table moz_items_annos has 0 records
• Table sqlite_stat1 has 17 records
• Table moz_meta has 5 records
• Table moz_origins has 7875 records
• Index sqlite_autoindex_moz_inputhistory_1
• Index sqlite_autoindex_moz_hosts_1
• Index sqlite_autoindex_moz_bookmarks_deleted_1
• Index sqlite_autoindex_moz_keywords_1
• Index sqlite_autoindex_moz_anno_attributes_1
• Index sqlite_autoindex_moz_origins_1
• Index moz_places_url_hashindex
• Index moz_places_hostindex
• Index moz_places_visitcount
• Index moz_places_frecencyindex
• Index moz_places_lastvisitdateindex
• Index moz_places_guid_uniqueindex
• 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_bookmarks_guid_uniqueindex
• Index moz_keywords_placepostdata_uniqueindex
• Index moz_annos_placeattributeindex
• Index moz_items_annos_itemattributeindex
• Index moz_bookmarks_dateaddedindex
• Index moz_places_originidindex

Task: _refreshUI

I want to add that I can't mitigate this issue, as looks like "browser.places.useAsyncTransactions" preference was deleted in about:config.

Changing summary, as I reproduced bug #1540669 again.

I'm not sure this effectively has STR, is it reproducible starting from a clean profile, or is there a profile we can use to try reproducing?

I'm also not sure how we can tell if this affects old versions or not.

True, clearing status-firefox <69 for now.

About STR, it's same as in bug bug #1540669 Comment #12, which I can still reproduce, so:

1. Create new ~50 bookmarks.
2. Open about:support and press "Verify Integrity" button under "Places Database" section
3. Restart browser
4. Add new ~20 bookmarks
5. Open ~10 bookmarks from #1 and delete them
6. Readd them and see that they will be placed in incorrect and wrong order in folder in Library - in most cases before these ~10 bookmarks added in #5
   if not
7. Move recently added bookmarks
   and bug should be reproducible now.

About this dataloss issue - only new history and new bookmarks wasn't saved from time which this undeletable bookmark appeared,
moved (or probably also removed) bookmarks were not moved (and probably also not removed).

I will create new profile and import bookmarks from HTML (as JSON contains also favicons and I'm also looking on some odd issue with disappearing favicons from bookmarks in Library after some time), but unfortunately I won't be having that much time for this before 2019-06-24.

Profile contains too much private and personal data, so unfortunately I won't be able to allow and permit to share it.

I ran a few reordering tests, and the only case where I noticed a disconnection between the ui and the database was when dropping a selection on itself, in that case the UI doesn't reflect the changes. We should probably disallow dropping on the current selection anyway, it's worth tracking/investigating that problem, but it should only be a visual problem in that edge case, closing and reopening the view (either library or sidebar) should solve it, so nothing too serious.

I also tried reproducing your exact problem with your steps, but I was unable to.
Some of the steps are too generic to be sure I did exactly as expected. For example, how should I add and remove bookmarks, just starring/unstarring?
Is the verify integrity step strictly necessary to cause the bug? Did you wait for its completion before restarting?

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

how should I add and remove bookmarks, just starring/unstarring?

Yes, I'm using Star UI.
But bug is also reproducible when I open bookmarks from Library, delete them there and re-add them either by "Select All Tabs" => "Bookmarks Tabs..." or by Star UI

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

Is the verify integrity step strictly necessary to cause the bug? Did you
wait for its completion before restarting?

Probably not, but I'm doing it before long time session browsing to clean leftovers of unmovable bookmarks and I'm always waiting for its completion.

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

For more information, please visit auto_nag documentation.

Setting at P5 until we find an easy way to reproduce.

Easy way to reproduce second part of this bug and follow-up of bug #1540669 is in comment #10.
Only undeletable bookmark issue is very hard to reproduce and happened fortunately just few times, but unfortunately few too many.

Is this going to be worked on for 69?

(In reply to Kate Hudson :k88hudson from comment #16)

Is this going to be worked on for 69?

We still don't have good STR to debug it starting from a clean profile. We fixed what we could reproduce already in bug 1540669.
So no.

Is p5 still the correct priority setting for this?

yes, it's not actionable until we get reproducible STR.

Even in new profile, with imported bookmarks from .JSON file, I can still reproduce issue, that moved and newly added bookmarks are placed in incorrect and wrong order in folder in Library, so it's not borked profile issue, as I was thinking at first.

@ Mark Banner (:standard8) - I would like to request new debug build based on latest patches and latest Nightly, like it was done in bug #1540669 comment #10, to help diagnose this bug again and deeply in detail, as it still happening and I'm can reproduce it after few tries. Or maybe you have other ideas how can I help you with fixing it? Thanks in advance!
Thankfully I didn't encounter ever again this undeletable bookmark while sorting and playing in Library with folders and bookmarks.

Just to say I've seen this, and I'll try to get to it early next week.

Any luck, Mark? Something we can to do add diagnostic info?

(In reply to Liz Henry (:lizzard) from comment #22)

Any luck, Mark? Something we can to do add diagnostic info?

Yes, we need to add more diagnostic info, or provide a build that does that. Unfortunately events have just overtaken things at the moment, and I haven't been able to get around to doing that.

I'm hoping that sometime in the next couple of weeks I can. In any case, I suspect this is more an edge-case as we're not seeing lots of reports of this.

FYI - I can still reproduce bug easily and often in my case, especially when I'm sorting many bookmarks in one go in Mozilla Firefox. I'm just hoping that I will be still around here at Bugzilla and I will be still using Mozilla Firefox that time to help Mozilla fixing this bug, because lately more and more, I'm thinking on switching to other browser per pilling more and more unfixed regressions and my patience has its limits, especially for bugs which breaks my workflow, productivity and efficiency. Not to mention latest MegaBar feature, which I read that I wouldn't be able to disable it in future, as hidden preference to control this will be deleted, doesn't encourage too.

I've just found a bit of time to look at this. Thankfully, I also discovered I could go back and get the patch from the try build I did previously, as I'd lost it locally.

Here's the new build, please could you give that a go? https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/Gwgi7SYrSHS59JiP-QR8oA/runs/0/artifacts/public/build/target.zip

As before, we probably just need the part where it goes from good to bad, though having earlier info may help.

(In reply to Mark Banner (:standard8) from comment #25)

I've just found a bit of time to look at this. Thankfully, I also discovered I could go back and get the patch from the try build I did previously, as I'd lost it locally.

Here's the new build, please could you give that a go? https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/Gwgi7SYrSHS59JiP-QR8oA/runs/0/artifacts/public/build/target.zip

As before, we probably just need the part where it goes from good to bad, though having earlier info may help.

Thank you very much for this, I really appreciate this!

STR:

1. Have about ~1000 unsorted bookmarks in "Other Bookmarks" folder
2. Open these website pages:
   https://www.aptekagemini.pl/akneroxid-10-zel-50g.html
   https://www.aptekagemini.pl/akneroxid-5-zel-50g.html
   https://www.aptekagemini.pl/svr-sebiaclear-serum-30ml.html
   https://www.aptekagemini.pl/svr-sebiaclear-krem-p-tradz-active-40ml.html
   https://www.aptekagemini.pl/svr-sebiaclear-krem-mat-40ml.html
   https://www.aptekagemini.pl/ducray-keracnyl-serum-30ml.html
   https://www.aptekagemini.pl/ducray-keracnyl-pp-krem-p-niedosk-30ml.html
   https://www.aptekagemini.pl/ducray-keracnyl-control-krem-30ml.html
   https://www.aptekagemini.pl/flos-lek-anti-acne-antybakteryjny-zel-punktowy-20ml.html
   https://www.aptekagemini.pl/flos-lek-anti-acne-antybakteryjny-krem-matujacy-50ml.html
   https://www.aptekagemini.pl/lrp-effaclar-duo-krem-40ml.html
   https://www.aptekagemini.pl/la-roche-posay-effaclar-duo-krem-zwalczajacy-niedoskonalosci-40ml-103927.html
   https://www.aptekagemini.pl/la-roche-posay-effaclar-k-odnawiajacy-krem-do-skory-tlustej-40ml.html
   https://www.aptekagemini.pl/pharmaceris-w-krem-wybiel-mel-int-n-n-30ml.html
   https://www.aptekagemini.pl/pharmaceris-w-serum-n-przebarw-30ml.html
   https://www.aptekagemini.pl/pharmaceris-t-sebo-almond-peel-krem-peelingujacy-ii-stopien-50ml.html
   https://www.aptekagemini.pl/pharmaceris-t-sebo-almond-peel-krem-peelingujacy-i-stopien-50ml.html
3. Add website pages in step #2 to "Other Bookmarks" (in my case - manually, one by one, using Star UI)
4. Remove added bookmarks in step #3
5. Redo step #2 and step #3
6. From all website pages addresses remove "www." part and open it, so in end it will look like:
   https://aptekagemini.pl/akneroxid-10-zel-50g.html
   https://aptekagemini.pl/akneroxid-5-zel-50g.html
   https://aptekagemini.pl/svr-sebiaclear-serum-30ml.html
   https://aptekagemini.pl/svr-sebiaclear-krem-p-tradz-active-40ml.html
   https://aptekagemini.pl/svr-sebiaclear-krem-mat-40ml.html
   https://aptekagemini.pl/ducray-keracnyl-serum-30ml.html
   https://aptekagemini.pl/ducray-keracnyl-pp-krem-p-niedosk-30ml.html
   https://aptekagemini.pl/ducray-keracnyl-control-krem-30ml.html
   https://aptekagemini.pl/flos-lek-anti-acne-antybakteryjny-zel-punktowy-20ml.html
   https://aptekagemini.pl/flos-lek-anti-acne-antybakteryjny-krem-matujacy-50ml.html
   https://aptekagemini.pl/lrp-effaclar-duo-krem-40ml.html
   https://aptekagemini.pl/la-roche-posay-effaclar-duo-krem-zwalczajacy-niedoskonalosci-40ml-103927.html
   https://aptekagemini.pl/la-roche-posay-effaclar-k-odnawiajacy-krem-do-skory-tlustej-40ml.html
   https://aptekagemini.pl/pharmaceris-w-krem-wybiel-mel-int-n-n-30ml.html
   https://aptekagemini.pl/pharmaceris-w-serum-n-przebarw-30ml.html
   https://aptekagemini.pl/pharmaceris-t-sebo-almond-peel-krem-peelingujacy-ii-stopien-50ml.html
   https://aptekagemini.pl/pharmaceris-t-sebo-almond-peel-krem-peelingujacy-i-stopien-50ml.html
7. Add website pages in step #6 to "Other Bookmarks" (in my case - manually, one by one, using Star UI)
8. Open "Library"
9. Play with bookmarks by moving them, but try moving only newly added bookmark with "www." or without "www." part
   and see what I can see on screencast, that moved bookmarks are placed in incorrect and wrong order in folder in Library

After some longer browsing session newly added bookmarks will be also affected, so they won't be added at bottom, but some place above.

The strange thing with this log is:

12:59:44.036 Pre validating order Bookmarks.jsm:1361:15
12:59:44.578 Bad order in unfiled_____ Bookmarks.jsm:117:11
12:59:44.963 Post validating order Bookmarks.jsm:1409:15
12:59:45.504 Good order in unfiled_____ Bookmarks.jsm:117:11

So it has gone from a bad order to a good one. It doesn't appear to go to a bad order again later on.

Would you be able to get one where it starts off good, then goes bad?

Please watch my screencast, as you can easily see there, how Library behaves on my end with STR from comment #28, when I'm moving bookmarks in bad and broken Library mode. I copied whole log of Browser Console from start. Nothing more was there to copy. Should I redo test maybe?

I just had a bit of a play around. I think there may be an issue moving multiple bookmarks up to the top of the view and then down again, e.g. moving a block of six bookmarks up to be the underneath the second item actually puts it at the top of the view. My best guess at the moment, is that the views are out of sync with the backend database - the database is always ending up valid, but the views are slightly different.

This is probably to do with the index numbers in the notifications. I'll try and poke a bit more later in the week.

I think I now have STR for this:

1. Have a profile with a reasonable amount of bookmarks in one folder, e.g. 25.
2. Go to about:support and run Verify Integrity in the Places Database section.
3. Restart Firefox
   (steps 2-3 ensure a clean and valid database).
4. Open Show all bookmarks and go to the folder.
5. Select the first two bookmarks, and drag them down a few places.
6. Select a different (single) bookmark
7. Drag it up to in-between the two bookmarks that are now at the top of the list.

Actual Results

=> The single bookmark moves to the top of the list.

Expected Results

=> The single bookmark moves to in-between the first two items.

This doesn't happen if I don't do step 5.

Also, I just noticed that this happens if I do something similar but further down the folder - i.e. drag a few items down, then insert something into the place they would have been.

Awesome! \o/ I'm looking forward to testing some test build, if needed of course. ;)

Any update?

I found some additional odd issue, which is probably related to this bug and maybe be some more clue, how to finally fix this annoying issue.

STR:

1. Add these 4 website pages as bookmarks:
   https://github.com/wchen342/ungoogled-chromium-android
   https://github.com/macchrome/winchrome
   https://github.com/macchrome/chromium/releases
   https://github.com/macchrome/droidchrome
2. Open them
3. Delete them
4. Readd them as bookmarks
5. Select first and last bookmark, and open them
6. and enjoy bookmarks ridiculous madness moving anywhere they want in bookmarks folder

I managed to have a look at this a week or so ago, and discovered that the backend database is fine, the notifications are probably fine, but somehow the indexes of the entries in the view (the bit that governs what is actually displayed and tells actions what indexes are being moved etc) are getting out of sync. I couldn't figure that out at the time and need to talk to Marco about it.

Hopefully I might get time in the next week or two to dig in further - it is still on my list to look at.

I haven't been able to get back around to looking at this. This comment reflects the status of where I got to:

(In reply to Mark Banner (:standard8) from comment #36)

I managed to have a look at this a week or so ago, and discovered that the backend database is fine, the notifications are probably fine, but somehow the indexes of the entries in the view (the bit that governs what is actually displayed and tells actions what indexes are being moved etc) are getting out of sync. I couldn't figure that out at the time and need to talk to Marco about it.

The view code appears to be the issue, but fixing that was tricky. When I last spoke to Marco, the suggestion was that we really need to rewrite our query and view code preferably not based on the tree code. Unfortunately that could also do with being coupled to a UI rewrite.

In short, I think this is too complex to fix by itself, and the additional work needed is too much for me to fit in on the side at the moment, hence un-assigning for now.

Still thank you very much for your report back! I'm really appreciate it!
Looks like this issue is much more complex and complicated. Could it be that it's in some way related to enabled ASync PlacesTransactions? As I'm also using and testing Waterfox Classic and Pale Moon, because I still need few XUL extensions, which don't have any real replacements and in these browsers this issue doesn't seem to occur (or maybe I'm using them not that much as Mozilla Firefox, so I didn't encounter it yet). What do you think about it?

(In reply to Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.) from comment #39)

Looks like this issue is much more complex and complicated. Could it be that it's in some way related to enabled ASync PlacesTransactions? ... What do you think about it?

Highly possible as that changed how some things work. Reverting those is not something we'd do as that would be a backwards step.

This happens to me randomly on Firefox 94.0 (since like 80.0+).

What I noticed is that it is more probable to occur when:

• there are 2 Firefox windows open,
• the bookmarks folder is in your Bookmark Toolbar,
• and you modify it from it's popup menu (drag&drop to move an item or dropping in new one).

It is even more probable when the background window is the Library showing that particular Bookmarks directory.

Maybe this helps a bit with reproducibility. Still this is quite rare (like twice a day) and random.

The severity field for this bug is relatively low, S3. However, the bug has 4 duplicates.
:mak, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Still affecting Firefox 104.0.2 (and earlier versions).

I can now confirm that this happens way more often when the Library window showing the affected Bookmarks directory is open in the background.
Any clues why?

With "about:support#place-database" (and #1738086, #1752736 done) it is now much easier to fix this problem when it occurs by quickly running the places' database integrity check, but still... this issue shouldn't happen at all in the first place...

> Task: _refreshUI

Is this the thing that fixes the problem? Can this task alone be executed manually to confirm this?

Fwiw, closing and reopening the view/library would be the same as refreshUI.

@Marco Bonardo

Fwiw, closing and reopening the view/library would be the same as refreshUI.

Closing and reopening the Bookmarks Library (Ctrl+Shift+O) does not fix the Bookmark Toolbar's submenus.
So it either does not call _refreshUI, or places' database integrity check does something more that matters.

Bug #1756382 was closed as a duplicate of this one, but the potentially helpful information from the original report wasn't included here.
Quoting the important part:

(James Teow [:jteow])

Video of the behaviour

I suspect it may have something to do with a syncing issue between the database and code in toolkit/components/places/Bookmarks.jsm that is simulating changes of the index positions in JS to avoid calling the database.

(In reply to Piotr Henryk Dabrowski from comment #51)

Closing and reopening the Bookmarks Library (Ctrl+Shift+O) does not fix the Bookmark Toolbar's submenus.

Yes, of course it doesn't because it's different views, I was referring to the Library. _refreshUI affects all the views... It should just not be necessary.