Closed Bug 86668 Opened 23 years ago Closed 22 years ago

Custom XUL app freezes after manually resizing window (and sometimes after scrolling tree panes)

Categories

(Core :: XUL, defect)

All
Windows 2000
defect
Not set
major

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: tupshin, Assigned: jag+mozilla)

Details

Attachments

(2 files)

I have a custom XUL window that includes 6 different RDF trees (which are manually built via JavaScript). I have no code that is triggered by resize or scroll events, but it is very easy to freeze this app completely by resizing the whole window which resizes each tree widget within the window. It is somewhat harder, but still possible, to freeze it by scrolling the individual trees within the window. I have had very little luck reproducing this problem in a simple case. Substantial simplifications of my XUL no longer exhibit this prolem, and standalone test cases fail to reproduce it. I am attaching the relevant xul (in hopes that somebody can spot structural problems that could be causing this, though it is not functional standalone, since it relies on javascript and our XML server in order to function. I am unable to get any crash logs since mozilla doesn't actually crash, just freezes indefinitely (with none of my javascript code executing). I'm hoping that somebody might either see some problems in the xul, or can provide suggestions how to debug this. If necessary, I can probably send an XPI to a relevant developer that can reproduce this.
QA Contact: sairuh → claudius
I see three things in this bug report by reading the first sentence: * XUL * window * tree It's practically screaming toolkit. (And I'm on dial-up, so I'm not going to attempt to reproduce the hang ;-)
Assignee: blake → trudelle
Component: XP Apps: GUI Features → XP Toolkit/Widgets
QA Contact: claudius → aegis
Is there any possibility that you could run this in a debug build, and break repeatedly in the debugger, noting the stack trace, when mozilla gets into this hang. That (possibly) may shed some light into where it is (or was) at the time of the hang. [And by the way, is this a 'hang' in the sense of xul layout never completes, or in the sense of UI-gone-dead].
oh boy a tree bug. doubtful this will get fixed. --> hyatt for 1.0
Assignee: trudelle → hyatt
Target Milestone: --- → mozilla1.0
FYI: the whole UI freezes with 100% CPU utilization on Windows 2000. I'm happy to try getting a stack trace with a debug build. Is there a place to download debug binaries or do I need to build my own?
You'd need to build your own. There aren't pre-built debug builds available anywhere (one reason being that if you don't have the debug libs that are installed by the compiler, then you wouldn't be able to run a debug build on your system anyways).
May God have mercy on us all. The 212 bug spam-o-rama is Now!
QA Contact: aegis → jrgm
Status: NEW → ASSIGNED
Target Milestone: mozilla1.0 → mozilla1.0.1
I am experince this bug as well - an embed build off RC1, all custom XUL - I will attach an example tree to see if this helps anyone debug. I've run the app in the debugger but I don't know where to set a break point and hung application never triggers a breakpoint/crash/etc that would allow me to get a stack.. but I am not that skilled in VC++'s debugger.
Attached file tree that may cause the lock up (deleted) —
Okay, I think I've solved my problem - the tree element needs a height value, otherwise the hang occurs. This bug looks to be a dup of bug #121583 Thanks to carlos@rovia.com for the assist in fixing/helping find a workaround.
I ran into this problem again, and adding a height attribute didn't fix this one, but: http://bugzilla.mozilla.org/attachment.cgi?id=82269 Fixed it.
--> default owner
Assignee: hyatt → jaggernaut
Status: ASSIGNED → NEW
Target Milestone: mozilla1.0.1 → ---
so this is worksforme, right?
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: