Closed Bug 807581 Opened 7 years ago Closed 7 years ago

bookmark button causes Janks


(Firefox :: Untriaged, defect)

19 Branch
Windows 7
Not set





(Reporter: mayankleoboy1, Unassigned)


(Depends on 1 open bug, )


(Whiteboard: [Snappy])

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/19.0 Firefox/19.0
Build ID: 20121031030750

Steps to reproduce:


1. Bookmark a few (5-6) pages. Even google,wikipedia and newtab pages will do.
2. Open them from the bookmarks button.
3. Wait for the pages to load completely.
4.Start the profiler.
5. Hover mouse over the Bookmarks button. A large jank can be seen in the profiler.

STR2 :
1. Click once on the Bookmarks button.
2.Start profiler
3. Hover mouse on the Bookmarks button. Observe large janks, though smaller than the previous STR.

Fun Fact : if you use the Bookmarks button, after the STR,  enable the "Bookmark Toolbar". Then if you hover mouse over the toolbars Bookmark button, no Jank.
And Vice Versa.

Actual results:

Large janks

Expected results:

No jank or minimal.

Attaching the profile :

This profile was taken after all the tabs were completely loaded. This is just me repeatedly bringing mouse to-and-away from the Bookmark button
Ok, this is not confined to the Bookmarks button only.
It also happens if you have "Menu Bar" enabled, and open a bookmark from there.Then the bookmarks button there causes janks.

Or if you have the "Bookmark Toolbar" enabled, opening bookmarks from there and then hovering mouse over the bookmarks button causes janks.

These janks remain till browser is closed.
It can be removed only if you change the layout of the browser through the "customize" option.
Summary: After opening bookmarked pages, the bookmark button causes Janks → bookmark button causes Janks
I'm not able to reproduce on FF 19 2012-11-06 on Win 7 x64. Can you please attach a screenshot with the problem ?
adding a screenr capture :


1. opened nightly with a clean profile. install the profiler.
2. initially,hovered mouse repeatedly over the bookmark button to show there are no janks in the profiler.
3. Clicked the bookmarks button. Scrolled through some bookmarks.
4. Mouse hovered over the bookmarks button again. 
5. Note  the huge janks in the profiler correspond to when mouse hovers over teh bookmarks button.
This is more reproducible if you enable "use small icons" option.
 You can also try to do this :

1. open   Set time to 600.

2. Open a new Nightly window.
3. Click open several (8-10) bookmarks from the bookmarks button. 
4.Make sure that both the windows are visible simultaneously on the screen. 
5. Strart the V8 balls benchmark.
6.Move the mouse to the bookmarks button. See that there is a clear dip in the V8 benchmark FPS line.
i think this is the regression range :

Last good nightly: 2012-08-21
First bad nightly: 2012-08-22

Taras, you might be the one that can take this bug forward. Anything in that range which might have triggered this?
Whiteboard: [Snappy]
Probably bug 812904 is a duplicate. There's a profile there, where nsCSSRendering::PaintBackground takes 72,6% of the time.
Ever confirmed: true
Now, opening the bookmarks button causes the browser to jank severely on minimizing and maximizing. I dont think this was happening earlier.

Profile :


1. Open the bookmarks button. Browse through the bookmarks.
2. Try to minimize / maximize the browser.
3. You can see large janks.

To stop the janks, right click on menu bar - > customize.   Do nothing there. Just close the 'customize; menu. Now if you try to maximize/minimize , it will be smooth.
Do the steps in comment #0 still reproduce the bug? The steps in comment #9 are different.
STR of comment #0 are still reproducible.

Is comment #9 a different bug ?
Maybe not. It's hard to tell.

If you disable layers acceleration, does the bug go away?
i can repro both comment #0 and comment #9 with layers.acceleration.disabled = true.

Some additional info that might be useful :
I have large number of bookmarks , 505.
A submenu in bookmarks has ~50 bookmarks, that covers the vertical screen space.
Some bookmark submenus are 5 hierarchial level deep.

comment #9, wasnt clear enough.  There is jank only if you click on the "restore window" button in the titlebar (the button between "close" and "minimize", which makes the window smaller.) And when you restore the window, there is another jank.  Using the Windows7 AeroSnap feature :  Snapping the nightly window to the sides causes no janks. But if you AeroSnap the nightly window to the top, there is a jank.
If you minimize Nightly to the taskbar and restore from there, there wont be any jank.
I suspect changeset 2a39d3361d72 may be forcing us to synchronously repaint a lot of stuff. I'll try making a try build with that backed out.
using win32 build from here :

comment #0 is reproducible in *all* cases , except : when you use setting  "show icons" + uncheck "use small icons" (which is  the default setting).
The profile here looks just like the profile in bug 794246 and implicates GDI.
Er rather, implicates GDI/D2D interop.
we have an increasing number of reports about the issue, but it's often hard to distinguish them:
bug 829563
bug 812904
bug 820247

All of them seem related to 2 issues:
1. without hwa it feels faster
2. but still after some openings they slowdown
And all of them started in Firefox 18

Roc, which is the bug the investigation is going on, this one? do we have separate bugs for the 2 issues? should we dupe everything to bug 794246?
Depends on: 794246
This bug is still repro in the latest Nightly, with HWA on or off.
This does not occur *only* when the size of the icons is left at default size.

After the button starts lagging, the only way to 'reset' the  janks is to right-click on the titlebar and select customize.
(In reply to Marco Bonardo [:mak] from comment #19)
> Roc, which is the bug the investigation is going on, this one? do we have
> separate bugs for the 2 issues? should we dupe everything to bug 794246?

Please close the ones that were fixed by 794246, and we'll re-investigate the rest.
A new profile with latest nightly would be very helpful.
Depends on: 830697
OK, we're still spending most of the time drawing theme backgrounds, but I can't tell which ones from the profile. I'll need to try debugging it.
FYI, I filed bug 832641, which is probably a duplicate of this bug.

Summary of my observations: when painting top-level menu widgets (e.g. buttons on Windows, but it's a similar issue on Linux), it probably also re-paints (but doesn't display) all their sub-items/folders/menus which were previously displayed.

This issue is probably magnified by HW accel, but is not caused by it.

The obvious symptoms are jank when hovering/using menu items for which many sub items were already displayed (usually book/livemarks), but also slower resizing of the window (on windows, especially on FX18).

The issue becomes worse over time, since during the browsing session more and more menu items/folders are peeked.

When hiding the menu/bookmarks-toolbar, the problem goes away, and since this also destroys all the previously-displayed sub-items, after re-showing the menu the problem is still fixed - until enough items were displayed again (this is also much worse on FX18 than on nightly).

This issue is really hard to live with in firefox 18(/.01), but is somewhat better in nightly, possibly due to the fix of bug 794246.
Depends on: 832641
The offending commit appears to be 1f6cd8529ae9	from the patch of bug 783449, great job by  'Alice0775 White' who tracked it. I've reverted the patch on Windows and been testing/using fx18.01 with the reverted patch for a day now and didn't notice a regression (and the bookmarks jank is gone).

See bug 832641 comment #7 for further info.
cant repro this anymore after bug 832641.  Resolved fixed for me.
Thanks a lot for fixing this extremely annoying bug. :-)
Closed: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 832641
Following bug 832641 fixed.
Duplicate of bug: 832641
You need to log in before you can comment on or make changes to this bug.