Closed Bug 54354 Opened 24 years ago Closed 24 years ago

The UI is unresponsive when lots of content inside a tabpanel

Categories

(Core :: XBL, defect, P3)

x86
FreeBSD
defect

Tracking

()

VERIFIED WORKSFORME

People

(Reporter: pete, Assigned: eric)

Details

To reproduce use the UI it on DEBUG builds. I counted, it takes 4 seconds for a css hover event to fire. I have dual P500's on my machine here so maybe that is the problem. ;-) --pete
well actually i kind of take that back. I produced a test case w/ a xul window containing only a button w/ a hover event atttached to it. It works fine. So can anyone shed any light as to why for example i click on a menu in the menubar on say the browser and i get this delay? Mozilla is virtually unuseable on my laptop. thanks --pete
Ok, i can pinpoint the root of the problem to tabs. If i comment out my entire tab control, UI response is back up. Is there anything i nned to know about using tabs these days? Changing summary to clarify problem. --pete
Summary: The UI is the slowest and most unresponsive i've ever seen it! → The UI is the slowest and most unresponsive when using tabs
Ok, i can pinpoint it one step further. It is occurring when using tabs w/ nested overlays. I have an overlay that has a tabcontrol, then from that overlay, i have a set of other overlays which contain the content that appears in each element w/in the tabpanel. Whether this is an overlay problem or a problem w/ large content inside of the tab panel i'm not sure. I will test now. --pete
Ok, to fully clarify, this is a content issue w/in a tabpanel. If you put say a container like a box inside a tab panel that has lots of child elements, the UI falls apart. I would guess that this could be an xbl issue, since i think tabs are now living in xbl? Updating summary and changing component to xbl --pete
Component: XP Apps: GUI Features → XP Toolkit/Widgets: XBL
Summary: The UI is the slowest and most unresponsive when using tabs → The UI is unresponsive when lots of content inside a tabpanel
over to default xbl owners.
Assignee: ben → hyatt
QA Contact: sairuh → jrgm
The deck itself is still C++.
Assignee: hyatt → evaughan
Well, now i'm totally confused . . I just took the tabpanel code using the overlays and put in in a seperate xul window by itself. It is very quick and responds adequately. So this is actually *not* the problem. Something else is causing it to bog down, i just don't know what? I'll report back when i figure this out. I have to take things apart piece by piece. --pete
This has to be something deeper than xbl. Here is the scenario: I have the theme builder running, i commented out all js and have only xul and css. I click on a tab and it takes about 20 seconds for it to display it's contents. Then i start clicking on other tabs and response becomes normal. If i continue to click on the tabs at a steady rate about 20-40 times then i get a UI freeze, my CPU goes from 0% to 75%. This lasts for about a minute or two then the UI starts to respond again. I click for another 20-40 times and same thing CPU is at 75%. This seems like some kind of loop issue. I don't know where this bug should be . . . This is very nasty! --pete
I lied! Make that 90%-100% CPU usage . . ;-) --pete
Set 'user_pref("nglayout.events.showHierarchicalHover", false);' in prefs.js and see how much of a difference that makes.
Thanks John. Looks like this fix was checked in yesterday by nisheeth. http://bonsai.mozilla.org/cvsquery.cgi?module=SeaMonkeyAll&branch=HEAD&cvsroot=/cvsroot&date=day&who=nisheeth%25netscape.com I think this was it. Everything is working fine now. Changing resolution to worksforme Thanks --pete
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
Thanks for following up, Pete. Marking verified "what he said".
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.