Closed Bug 820247 Opened 7 years ago Closed 7 years ago
Bookmarks submenus MUCH slower in FF 18
.0+ (than in 17 .0 and earlier)
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20100101 Firefox/17.0 Build ID: 20121128204232 Steps to reproduce: I created a clean profile (without any add-ons). I set the preference: "user_pref("ui.submenuDelay", 0)" I accessed my bookmarks (17 top-level folders, and a total of 2,933 bookmarks, some extending 6 levels deep) from an icon on the Navigation Toolbar and from the menu item accessed via the FF Button. OS: Win7, x64, fully patched Actual results: In accessing the bookmarks from the icon on the Navigation Toolbar, there was a noticeable delay as the bookmarks displayed, particularly as the submenues displayed. The more tabs that were open, the longer the delay (even though my system reported 3250 MB of "available" physical memory). Dragging the mouse quickly from the top to the bottom of the bookmarks resulted in a significant visual "lag" as the highlighted bookmark attempted to catch up to the mouse. Same behavior in FF 18.0b1, b2 and b3. Behavior appears to get worse the longer that FF is open. Performance is better in FF "safe mode" (even though I'm using a clean profile, w/o any add-ons). Performance is much better if I access the bookmarks from the menu item via the FF Button (though even then performance degrades the more tabs that are open; I tested with a max of 20 tabs). When there IS a bookmark submenu delay, FF "response" is also slower on other UI items, such as closing tabs by middle-clicking on the tab. Expected results: The menues and bookmarks are really snappy in FF 17.01 and earlier (it doesn't seem to matter how many tabs are open). There is no lag as the mouse is dragged from the top to the bottom of the bookmarks menu, and the bookmarks submenues all "pop" open. No lag in closing tabs by use of a mouse middle-click. Snappy interface.
I just tested this with FF 18.0b4. With 4 tabs open, accessing bookmarks is reasonably fast from the FF Button (though not as fast as 17.0.1). Accessing bookmarks from an icon on the Navigation Toolbar continues to lack responsiveness. This is consistent with the "performance" in all prior builds of 18.0.
This problem continues, without change, in FF 18.0b6.
The problem continues, without change, in FF 18.0 RCb1. I have found however, that the bookmark menu responsiveness improves substantially if hardware acceleration is disabled (indicating some sort of architecture issue). But even with hardware acceleration disabled, I notice that there is more of a bookmark submenu delay when I access the bookmarks from an icon on the navigation bar, than when I access them from a menu item in the FF start button. I don't understand the performance differential.
Further, with hardware acceleration disabled, I notice that the bookmark submenus (accessed from an icon on the navigation toolbar) are snappy at first, but become slower and slower the longer the browser is used. The bookmark submenus accessed via the FF start button remain snappy (though my testing wasn't exhaustive). Surely some developer knows what they changed in FF 18 (from FF 17) to effect this radical degradation of performance.
This was very noticeable and jarring after updating to 18 today. Like Kent, it's better in safe mode for some reason. I tried independently disabling all extensions, plugins, and user chrome, but none of it made a difference.
Please retest on nightly to see if bug 794246 fixed this.
Just tested with firefox-21.0a1.en-US.win32.installer.exe (1/14/2013: 11:06p). No improvement.
For me this did not happen with FF 17 -- it started with FF 18. When I tried disabling Hardware Acceleration it did help the problem, but that changed the menu font from sans serif to a very small serif font. It also altered the default web font size to 24. After re-enabling HA, the menu font was restored, but the web font needed to be manually resized in Options.
This may not be related, but scrolling is also noticeably clunkier in 18 with smooth scrolling off. Someone new to Firefox might not notice, but it was very obvious to me when upgrading from 17. I hope this (the bookmarks folder bug and any related symptoms) gets fixed in 18.0.2 because it's bad enough to warrant rolling back to 17. I'm shocked that it somehow slipped past everyone for at least a month (except Kent).
Summary: Bookmarks submenus MUCH slower in FF 18.0b (than in 17.0 and earlier) → Bookmarks submenus MUCH slower in FF 18.0+ (than in 17.0 and earlier)
same problem and I confirm it's related to the hardware acceleration, disabling it fixes the issue. For me when I start the browser the menu is ok but it gets slower over time. The browsing experience remain snappy/normal even when the Bookmark menu is so slow it makes it look like the browser is about to crash. It's happening on Windows 8 x64 with an ATI HD5750(drivers 12.10 and 13.1)
I might be able to take this myself soon.
Assignee: nobody → matt.woodrow
I also can confirm this bug on 3 of my 4 machines. Disabling HWA definitely helps. I also can confirm that it's getting worse over time.
I can reproduce the problem too. I have found that the more folders I view in the bookmarks menu, the slower the menu becomes. If I go through every folder in my bookmarks, the menu takes more than 5 seconds to open. This happens in my current profile, in safe mode, and a brand new profile that I have imported just my bookmarks into. I also noticed that the problem is menu specific. If I browse the bookmarks from the toolbar button then the toolbar menu slows down, but not the Firefox menu. If I browse the bookmarks from the Firefox menu, the Firefox menu slows down but not the toolbar button menu.
Is this fixed by bug 832641?
Following bug 832641 fixed.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WORKSFORME
Resolution: WORKSFORME → DUPLICATE
Duplicate of bug: 832641
New to this forum, apologizing i I post the wrong way.. I am experiencing the same problem; redrawing of bookmarks in 18 or above is painfully slow. all works fine on 17.0.1 using Windows 8. I read the bug was resolved (832641) but when installed 18.0.2, problem persists. Was a fix introduced already?
The fix will appear in Firefox 19.
> The fix will appear in Firefox 19. Which will be released on February 19. If you want it before then, you could switch to Beta releases, see beta.mozilla.org.
Much appreciated. installed 19.B4 and all seems to be working fine.
You need to log in before you can comment on or make changes to this bug.