firefox: Ctrl+D to bookmark w/tags only causes bookmark menu slowdown

[Alan Jenkins]

If you use the keyboard shortcut Ctrl+D to create a new bookmark, it's filed in the "bookmark menu" folder unless you tell it otherwise.

If you're a heavy bookmark user, this leaves you with hundreds of entries in the bookmark menu. (Because you're using _tags_ to keep them organized, there's no other reason to touch the folder). The resulting menu takes 30 seconds to load (the first time it's opened) on my Core2 machine. That's not very good behavior.

Annoyingly, this is inconsistent. if you use the mouse to click on the star instead, it defaults to "unsorted bookmarks", which avoids the problem. But I'm a keyboard user, dammit. The problem is that keyboard shortcuts are tied to menu items, i.e. the "bookmark this page" item on the bookmark menu. So it's logical that this action defaults to the bookmark menu...

The bookmarking widget doesn't remember the last setting used; there's apparently no way to set a more appropriate default.

I don't know how to resolve it. Personally I'd be happy to just switch the default, and add "Unsorted bookmarks" to the bookmark menu, but I suspect it'd annoy some existing users.

That said, the situation is *much* better than when I first noticed this. I've just been able to fix it by moving 1000 bookmarks over to "Unsorted bookmarks" in under 10 seconds (on a cheapo netbook SSD!). Previously, the bookmarks manager didn't optimize this case; it basically wasn't able to complete it before I gave up and killed firefox. The interface for dragging+dropping that many bookmarks is not very good, but at least it seems workable now.

Personally I feel supporting heavy bookmark use should be a long-term aim for Firefox. Encouraging bookmark use is good for security, and good for privacy/robustness in lessening dependency on search engines. I guess the problem is that Firefox tries to support both tags *and* folders.

ProblemType: Bug
DistroRelease: Ubuntu 11.04
Package: firefox 5.0+build1+nobinonly-0ubuntu0.11.04.2
ProcVersionSignature: Ubuntu 2.6.38-10.46-generic 2.6.38.7
Uname: Linux 2.6.38-10-generic x86_64
Architecture: amd64
Date: Fri Aug 19 09:20:48 2011
FirefoxPackages:
 firefox 5.0+build1+nobinonly-0ubuntu0.11.04.2
 flashplugin-installer N/A
 adobe-flashplugin N/A
 icedtea-plugin N/A
ProcEnviron:
 LANGUAGE=
 PATH=(custom, user)
 SHELL=/bin/bash
SourcePackage: firefox
UpgradeStatus: Upgraded to natty on 2011-06-19 (60 days ago)

[Alan Jenkins (aj504)]

Rats, I forgot this was an orca-specific problem. Without Orca, it's more like 5 seconds. It needs Orca running (and 100's of items on the bookmarks menu) for the 30 second delay.

What's odd is that there's no delay at all if orca is started _after_ the bookmark menu has been populated, and I can't see any loss of functionality...

[Alan Jenkins (aj504)]

It's down to 16 seconds now, in 11.10. (After moving all my bookmarks back to the menu). And without the general menu bar plugin, it's much lower. So it's seems to be improving...