58149 - Switching between Open popup menus are slow

Status: RESOLVED WORKSFORME

(Core :: XUL, defect, P3)

Description

[Tony Tsui]

Switching between open popup menus are slow if the URL bar is active, ie the
caret is flashing ready for text input.

To reproduce Normal Behaviour:
Make sure the URL bar is not active, ie the caret is not flashing.
Open the Edit menu.
Move the cursor to the View menu item.
The view menu pops up fairly quickly.
Move back to the Edit menu item and the Edit menu pops up quickly.
Switching between the Edit and View menus is quick.

To Reproduce bug:
Make sure the URL bar is active, ie the caret is flashing and you can enter text
into it.
Open the Edit menu.
Move the cursor to the View menu item.
The view menu is slow to popup.
Move back to the Edit menu item and the Edit menu is slow to popup.
Switching between the Edit and View menus is noticeably slow.

Comment 1

[Jerry Baker]

I see this as well on Windows 2000. The difference here is that the URL bar does 
not have to be active in order to see this. In other words, it happens all the 
time. If you move quickly across the menu bar with the mouse, it leaves 
artifacts of the other menus. See attachment.

Comment 2

[Jerry Baker]

Attachment: Menu artifacts

Comment 3

[Christopher Blizzard (:blizzard)]

I see this in gtk, especially in mail/news when using drop down box with the
list of addresses.  It's XP.  roc, any ideas?

Comment 4

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Are you guys all talking about the same bug here?

I don't see any behavior that depends on URL bar activation. I do see transient 
artifacts similar to what Jerry noted, but different (mine cover the chrome as 
well). Jerry, can you reproduce the URL-bar behavior, or does that look platform 
dependent?

The new view manager removes the explicit repaint of the underlying window when 
popups are hidden --- it relies on OS repainting instead, which allows for OS 
save-unders. Tomi reported that this sped up Linux menus significantly. I'm not 
sure if it has any bearing on this bug or not.

Comment 5

[Jerry Baker]

The behavior is exactly as the original reporter noted, but it is independent of 
whether the URL bar has focus or not.

Comment 6

[Jerry Baker]

*** Bug 147104 has been marked as a duplicate of this bug. ***

Comment 7

[Jerry Baker]

Mass removing self from CC list.

Comment 8

[Jerry Baker]

Now I feel sumb because I have to add back. Sorry for the spam.

Comment 9

[Eugenia Loli]

Attachment: XUL is sucky slow

Ok, guys. Time for some optimizations. I spent 5 hours last night - up to 4
AM-, arguing with my readership about the attached screenshot (also viewable
here: http://www.osnews.com/img/1620/mozilla2.png )
The whole discussion is here:
http://www.osnews.com/comment.php?news_id=1620&limit=no (and some people say
that Mozilla 1.1 crashes on that page - but that's another bug, please file it
if it crashes for you - it works for me you see)

So, the deal is that the menus are SLOW to redraw. I can SEE them draw in front
of me, I can even describe the algorithm you are using for God's sake...

To reproduce, you will need to click on "File" and then move your mouse
fast-ish over the other menus, without leaving the menu area. When I do this, I
see all these terrible redraws. These redraws happen on all Mozilla versions
that I can remember. It happens on my Mandrake and Gentoo Linux as well, on the
same machine. And it ain't the theme. I can reproduce this on ALL themes I use.
The other native XP menus from IE or other windows app, DO NOT exhibit this
terrible slowness.

My machine:
Dual Celeron 533 Mhz, 3Dfx Voodoo5 AGP 64MB, 256 MB SDRAM, IBM 80 GB fast IDE
drive, WindowsXP PRO, Gentoo Linux 1.2, Mandrake 8.2.
I use my monitor at 1280x1024x32bit at 85 Hz.

I hope that this helps and I hope this issue is fixed. I had enough of it for
the past 2 years, but the main reason I sound so angry here, is because some
people just don't believe it, even after showing the screenshot on my site,
while others can EASILY reproduce the problem. Most of them are with Celerons,
if that tells you anything. Dual 533 should have been plenty enough to run
Mozilla's UI nicely. It isn't.

Please note, the HTML rendering is fast ok. The UI is not. And there is not
something like Galeon for Windows. KMeleon is behind schedule. Therefore,
Mozilla's UI have to be fixed to run faster.

Please let me know if you need more information.

Comment 10

[Keyser Sose]

Eugenia, please make sure you dont have any left over Mozilla profiles from long
ago. Those often times make the UI much less responsive. Delete the Profile
Directories, usually located in (if on XP) c:\documents &
settings\<user>\application data\mozilla\ If it still happens let us know.

Comment 11

[Phil Harper]

Attachment: older build but managed to produce same behave.

ok, having whacked my res up somewhat i can finally experience this one for
myself, windows 98 doesn't have the same trouble though.

Comment 12

[Eugenia Loli]

I did delete the whole Mozilla dir there. Relaunching and recreating a new 
profile from scrathc, yes, the UI is _still_ equally slow as before. It did 
not fix the issue. It seems that the problem is indeed more visible on 
WindowsXP or 2k.

Comment 13

[Eugenia Loli]

So, what's up with that bug (timing issue)? Mozilla 1.2 was released yesterday 
and that bloody bug is still there! Apparently a LOT of people experience it 
(from what I hear in my site and on my mailbox).
This bug is the reason I use IE over Mozilla. It really needs fixing.

Comment 14

[Ryan VanderMeulen [:RyanVM]]

Whoops, sorry about that

Comment 15

[Wayne Mery (:wsmwk)]

do you agree this is gone?  (note: reporter is unreachable)
WFM: 
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060921 Minefield/3.0a1
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060918 SeaMonkey/1.5a

Comment 16

[Wayne Mery (:wsmwk)]

WFM 
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060918 SeaMonkey/1.5a