I observed the following problem using a Nov 17 9:00 PM EDT pull. It had Chris'es new gtk code in it, so I suspect that is what is causing this. The problem is that the pulldown menus under the title bar are very slow. You dont notice it if you just pull down 1 menu, but if you pull a menu down and then slide the mouse horizontally across several menu headings so that they all get dropped it becomes quite apparent. This was with Red Hat 6.1/x86 , gtk 1.2.6, & libIDL from Orbit-0.5.

There were some rendering problems with menus right after the landing. Should be a lot better now.

I just tried it and its not fixed. Just to be clear, this is not the problem with the scroll bars being slow. That IS much better than it used to be. This problem is with the pulldown menus in the titlebar. To see the problem it is helpful to compare with communicator 4.7. Bring up the browser and depress the mouse button on top of the File menu. Now, keeping the button depressed, slide the pointer over to the Edit menu and then on through Go and Communicator. Even if you do this very quickly, communicator can keep up with what you are doing. Now try this with Mozilla. I would guess its about 100X slower. We probably do not need to be as fast as communicator, but it would be nice to be significantly faster than we are now.

Clearing FIXED resolution due to reopen.

changing component to xptoolkit menus. Blizzard, do you still think this is a significant problem for users? Do you still have time for it, or should we take it?

I think menus are pretty good. It's related to the fact that rendering on Linux is slow in general. It doesn't need a seperate bug. I'm not going to spend any time on it any more than the other rendering problems.

Linux rendering seems to be much improved (scrolling is much faster). The pulldown menus are still slow.

while the top pulldown menus on ns4.x are near-instant even on my p90, on mozilla they are almost unbearable.. and now testing the opening of the pulldown menus on athlon600, sliding mouse over the menubar button depressed, it's still sluggish, very noticeably so.. unacceptable.

> I think menus are pretty good. > It's related to the fact that rendering > on Linux is slow in general. General rendering doesn't seem as bad as the menus... > It doesn't need a seperate bug. I'm not going > to spend any time on it any more than the other rendering problems. Why on EARTH has this simple thing not been resolved before? I cannot believe that people can think that this is acceptable performance. Elementary things such as this should be sorted out before all the fancy features Mozilla has. For goodness' sake, even opening menus on the latest build causes half the menu to disappear and the "location" text box to appear in front of the menu.

I know what is going on here. I will look at this later.

Ok, what is going on here then? Share and someone else might fix it. Open source is a beautiful thing.

Updating QA Contact.

Pav seems to think he knows what's going on. It's his bug now.

Pavlov, I tried running mozilla w/o a windown manager. The pulldown menus are still slow, so the slowness is not due entirly to window manager interactions.

Mass-moving all M16 non-feature bugs to M17, which we still consider to be part of beta2

m18

they are pretty damn fast now. if anyone disagrees, please reopen.

yeah, they seem pretty zippy to me. verif on linux [opt comm] 2000.05.18.08.

what the hell.... :P i just noticed something weird. i have 2 linux machines lan, not connected to internet, no apps running over the network, network monitor shows absolutely no traffic between the two machines. now i start up mozilla, press mousebutton on the menubar and slide mouse horizontally across the menus, and the network meter gives 5kbytes/s traffic on the lan. traffic stops when i stop fiddling with the menus. whaaaaat is going on here?? :P huh?!