358863 - High CPU load and jumping of elements if bookmarks toolbar overflows

Status: RESOLVED FIXED

(Firefox :: General, defect)

Description

[mikaelelf]

User-Agent:       Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.8.1) Gecko/20061021 PmW-Fx/2.0
Build Identifier: http://releases.mozilla.org/pub/mozilla.org/firefox/releases/2.0/contrib/firefox-2.0.en-US.os2.zip

CPU load between 40-99%, slow performance. Seems to depend on: 1) Bookmarks Toolbar contains more bookmarks than it could show 2)FF:s window size,(big window-big trouble).

Reproducible: Always

Steps to Reproduce:
1.Start FF in Maximized window
2.You should have more bookmarks in "Bookmarks TOolbar" than it can show, or resize window until there is bookmarks that doesn't show.
3.

Actual Results:  
CPU is overloaded ~40-99%, FF:s performance is slow.

Expected Results:  
No CPU overload, normal performance

Using eComStation 1.2MR on:
Acer Aspire laptop, AMD Athlon XP-M 2600+
~760 MB RAM
SNAP Graphics (Vesa VBE 2.0 mode)

No problem with FF 1.5.0.7

Comment 1

[John Woods]

Using a fresh download of eComstation, and testing with both warpzilla firefox 2, and Peter Wielbacher's firefox 2, a window resize event is erroneously fired over and over.

This line of googlebarOverlay.xul will cause a race. Removing it clears the race. (True, we do not resize the toolbar when the user has too many buttons to fit inside the window, and maybe we should.) This only happens on the OS2 platform.

// event listener to update the search term buttons overflow status 
window.addEventListener("resize", googlebarRefreshSearchButtons, true);

There is another side effect. When a hbox node is larger than the window size,
the vertical scroll bar disappears. In my case it is the node ggb_parent_container. That node stays the same size, no matter the window size, which is supposed to be allowed. 
This is probably in preperation for the resize event, which is not in fact occuring. I would think that the horizontal scrollbar would disappear also.

Comment 2

[Andy Willis (abwillis)]

This issue has been reported by several people in the newsgroups and when FF2 was first released I worked with Bart on #netlabs and he worked out that it was when FF was resized so that not all the bookmarks in the Personal toolbar could show.  The odd thing is that not all pages seem to exhibit the issue www.nu.nl does.

Comment 3

[Peter Weilbacher]

johnrw, the reporter did not say that he was using Googlebar. I rather think that he is seeing what the "collect-all" bug 247116 is about: that there is some kind of loop involved in the bookmark chevron display, even without extensions. The reason for this may be the same as for Googlebar... Can you give me a hint how to debug where the window resize event comes from? How did you do that to find the Googlebar line?

Comment 4

[John Woods]

Peter, What I did was set a breakpoint in googlebarOverlay.js->addTerms using venkman. With the resize listener enabled, venkman will keep breaking in that function. Once you are in the breakpoint, look at the call stack. (Of course you must have include browser files checked for venkman.) Removing that listener, the cpu would idle correctly. Enabling it, the cpu was hovering around 70%. (My laptop fan comes on.) 

For the benefit of the others here... to produce this error reduce the window size horizontally to cover any of the unofficial googlebar toolbar buttons. The vertical scrollbar disappears. The listener only serves here to show that resize window events are being fired.

Comment 5

[John Woods]

Attachment: venkman profile during race

I shrank the window horz to halfscreen to cover some of the toolbar buttons here.
chrome://global/content/bindings/popup.xml and file:///D:/FIREFOX/components/nsMicrosummaryService.js are unusual.

Comment 6

[John Woods]

Attachment: venkman profile no race

Here is a venkman profile baseline of my system idling properly.

Comment 7

[John Woods]

http://www.mozilla.org/performance/jsprofiler.html states that will not do much good, and that quantify is the best tool. Since that is an IBM product, I hope someone watching has that tool.

Comment 8

[Andy Willis (abwillis)]

It may be related to bug 247116 but it is related to the height of the toolbar and the pages jumps up and down because of it.  This one is related to the width of he toolbar and jumps left and right because of it (at least here it is left and right).

Comment 9

[Peter Weilbacher]

Adapting summary a bit so that it is found for "jump".

I am going to test if this is somehow related to the theme changes I made in bug 314843 and bug 336997.

Comment 10

[John Woods]

Peter, I tried to get a developer OS2, or even a prerelease. Until Roderick at Mensys gets back to me, I will only be able to sympathize.

Comment 11

[Peter Weilbacher]

Attachment: Fix by using min-width

This simple fix seems to do it for me (actually, the first min-width does it already, but winstripe has them on menubar and the first-child properties, too, so I thought I add them there to be sure).

Interestingly, the SeaMonkey version of the toolbar.css file has a note /* DON'T DELETE! */ next to the min-width setting. If the Toolkit/winstripe version had it, too, I would never have removed it for the pmstripe version. I now added it again in this patch...

For everybody who wants to try this out, just place the line

   toolbar, menubar { min-width: 1px; }

into your userChrome.css.

Comment 12

[Mike Kaply [:mkaply]]

Comment on attachment 246569 [details] [diff] [review]
Fix by using min-width

r/sr=mkaply

Comment 13

[Peter Weilbacher]

mkaply, thanks that was quick. :-) Checked into trunk.

johnrw, many thanks for all your help with this problem and all the Googlebar debug builds that you sent me. I am very sorry that I never made the connection between the problems we discussed and min-width...

Comment 14

[John Woods]

Well I did discover a bug on firefox, mainly if you upgrade your eComstation's Firefox somehow... (I created a specific procedure that involves booting up and getting the firefox without loading the old 1.1 firefox using the commandline ftp) and getting it all setup, you can't install an extension to it. 

You see eComstation uses a ramdrive for temp files, and firefox tries to create a file named install-xyz.rdf... and that of course fails on a 16bit fat ramdrive. So maybe you guys want to join in and yell foul on the bug. OS2 is probably the last os that 16bit drives may be found on, that will still be able to run a modern browser. The bug is here https://bugzilla.mozilla.org/show_bug.cgi?id=360070

Or maybe you can let eComstation know they are going to have problems with Firefox 2.0 and the ramdrive type. The error message firefox gives back to the user blames the extension, for a malformed install.rdf!


I don't guess Roderick will be getting back to me on the os2.

Comment 15

[Peter Weilbacher]

Comment on attachment 246569 [details] [diff] [review]
Fix by using min-width

Would be great to get this OS/2 only fix also into FF 2.0.0.1.

Comment 16

[Daniel Veditz [:dveditz]]

Comment on attachment 246569 [details] [diff] [review]
Fix by using min-width

approved for 1.8 branch, a=dveditz for drivers

Comment 17

[Jay Patel [:jay]]

Peter or John:  Could you please help us verify this fix on OS/2?  If things work as expected now, please replace the "fixed1.8.1.1" keyword with "verified1.8.1.1".  Thanks!

Comment 18

[Peter Weilbacher]

Jay, that is a bit difficult as there are no OS/2 branch nightlies of Firefox (that I know of). I know that it works in my own build, but I am hesitant to verify using that.

Comment 19

[Jay Patel [:jay]]

Thanks for the feedback Peter, if it's working in your build, that's a good sign.  Hopefully someone with an official os2 build can verify this...if not, I'm sure we'll hear about it if it's still broken. :-)

Comment 20

[Felix Miata]

toolbar {min-width: 1px;} in userChrome.css on OS/2 FF2 fixes my problem with the Web Developer extension described at http://chrispederick.com/forums/viewtopic.php?id=1582.

Comment 21

[Peter Weilbacher]

Verified fixed on branch using Firefox 2.0.0.1, but trunk the toolbar on "Gecko/20061222 Minefield/3.0a2pre" acts weird anyway, so I cannot really see if this particular bug is fixed.