"Other Bookmarks" toolbutton takes too much space. This gets irritated.

Please add abilities.

1. Hide "Other Bookmarks" toolbutton
2. Rename the label
3. Move it to "Show more bookmarks" menu

I tried to move all bookmarks under "Other Bookmarks" to a newly-created folder but find that the move operation no longer works....

(In reply to lilydjwg from comment #1)

I tried to move all bookmarks under "Other Bookmarks" to a newly-created folder but find that the move operation no longer works....

Which "move" operation did you try? I was able to both drag bookmarks from the Other Bookmarks folder to another folder and use Cut and Paste to move bookmarks out of Other Bookmarks. Both of those should work for you as well.

If they don't both work please try in Safe Mode and a new profile and then report your issue in a new bug report.

Thanks, it's drag. I'll try later.

Yes, option to hide "Other Bookmarks" in Bookmark Toolbar is needed now, as it can not be hidden using standard and default methods.
It is also kinda illogical for me, why "Other Bookmarks" main folder is shown under "Bookmarks Toolbar" main folder, thankfully at least "Bookmark Menu" main folder is not shown there.
In my opinion, better will be finally get rid of "Other Bookmarks" main folder and its default save folder for bookmarks and make for it "Bookmarks Menu" main folder, last used one (with option to disable it, as as showing bookmark editor) or other one set manually by user (same as as Download folder), but it is for another bug.

The folder automatically goes away if it has no contents. In bug 1665389 and friends we'll move the default to not being the "other bookmarks" folder, and the default will follow your last selected folder as comment #4 suggests.

That seems like a sufficient solution here without adding Yet Another Option to remove this item (which we then presumably have to maintain forever, and which people have to find somewhere (ie has discoverability issues), etc. etc.). Am I missing something?

Why didn't Mozilla make it customizable tool button like the download tool button(hidden if empty)?

I dislike "last used folder" thing... It will be another discoverability issue.
Because I must have forgotten the last used folder. I'll have to look for where it was saved.

I don't like the "last used folder" idea either---I would end up casually-saved bookmarks scattered in wrong place over the time. Why do I want to save bookmarks in the same folder as last time? I either save it in a carefully categorized folder structure, or don't want to take effort and save it in an uncategorized place. (Yes, the "Other Bookmarks" was that uncategorized place.)

I prefer the "Other Bookmarks" to be a user-removed tool icon so that new users will see it and old users who don't want it to show up can hide it.

BTW I didn't reproduce the issue in comment 1.

(In reply to Alice0775 White from comment #6)

Why didn't Mozilla make it customizable tool button like the download tool button(hidden if empty)?

Because then it can't always show up in the same place as the bookmark toolbar items - the thinking is that we should slowly move away from having 3 separate "roots" for bookmarks -- it's confusing for users (who, esp. when used to other browsers, expect all their bookmarks to show up in the toolbar by default, unless they start moving things around), it's confusing in implementation, it just doesn't make a lot of sense.

Let's take the discussion around "last used" folder elsewhere.

Depends on D97211

Several add-ons store data in subfolders under "Other bookmarks". Those are not real bookmarks and displaying them is not useful to the user.

Please allow a way to hide that folder, as it is not under the "Bookmarks Toolbar".

Backed out for bc failures on browser_toolbar_other_bookmarks.js

Backout link: https://hg.mozilla.org/integration/autoland/rev/319dfe173ef9fe8c46117a05d96736c8b84b1be2
Log link: https://treeherder.mozilla.org/logviewer?job_id=322348573&repo=autoland&lineNumber=4545

https://hg.mozilla.org/mozilla-central/rev/e6cb8e3a5ef9
https://hg.mozilla.org/mozilla-central/rev/cc3876062efe

Is the plan to ship the "Other bookmarks" button in 84? In that case I think it would be good to uplift this patch.

(In reply to Tom Schuster [:evilpie] from comment #16)

Is the plan to ship the "Other bookmarks" button in 84? In that case I think it would be good to uplift this patch.

We'll be running an experiment on release, so it won't be enabled everywhere (see the pref). Still, we've already discussed requesting uplift, Micah will do it once North America is awake.

Comment on attachment 9188138 [details]
Bug 1674539 - Add option to hide Other Bookmarks button from bookmarks toolbar. r=jaws

Beta/Release Uplift Approval Request

• User impact if declined: Users will have no way to hide the "Other Bookmarks" folder from the toolbar.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Extensively covered by automated tests and the changes themselves are not large.
• String changes made/needed: Added a new string "Show Other Bookmarks" and its corresponding access key 'h' to the toolbar context menu.

Comment on attachment 9188138 [details]
Bug 1674539 - Add option to hide Other Bookmarks button from bookmarks toolbar. r=jaws

Canceling the beta uplift request for now, since we're getting regressions from landing this patch.

We're a week away from building the 84 RC build. At what point should we consider deferring the experiment until 85?

(In reply to Ryan VanderMeulen [:RyanVM] from comment #20)

We're a week away from building the 84 RC build. At what point should we consider deferring the experiment until 85?

While the two regressions from this bug are unfortunate I don't think they should cause the full experiment to be deferred. We would like to fix these before enabling the full feature, which if the experiment is successful would likely not happen until 85.

Hello,

I can confirm this issue is fixed on Firefox Beta 85.0b2 on Win 10, ubuntu 18 and mac OS 11.