Closed
Bug 37743
Opened 25 years ago
Closed 14 years ago
If error loading XUL files, partially constructed, invisible window remains and causes hang on exit.
Categories
(Core :: XUL, defect, P3)
Tracking
()
RESOLVED
INCOMPLETE
Future
People
(Reporter: sfraser_bugs, Unassigned)
References
Details
(Keywords: hang, Whiteboard: [nsbeta3-])
If there is an error loading a window XUL file, we don't properly clean up and
destroy the partially contructed window; the window stays around, is invisible,
and interferes with window layering and event dispatching.
For example, try clicking the 'Preferences' button in the AIM Sign On window
right now. You'll see errors about missing files in chrome://pref/skin. But note
now how you can't click between a browser window and the Sign on window to switch
between them, nor can you quit the app. We're left in a pretty horked state.
A similar thing happens when the window with bad XUL is not a dialog, but a
regular window.
Comment 1•25 years ago
|
||
mass-moving all bugs to m21 that are not dofood+, or nsbeta2+
Target Milestone: M18 → M21
Comment 3•24 years ago
|
||
This is the ghost of futured Mac bugs rattling his chains - any more recent
status on this bug?
Comment 5•23 years ago
|
||
The problem is not restricted to bad XUL. Simply not having enough cache, or
loading of some content being timed out causes this.
After there is this persistent phantom window, Mozilla usually becomes somewhat
unstable, naturally, and there is an increase in crash.
I would like to see this problem fixed before 1.0. Hang on exit is pretty severe
problem for average users.
I feel the incidence of this bug occurring is increased a lot in recent builds,
including 082408 trunk.
Severity: normal → major
Summary: If error loading XUL files, partially constructed, invisible window remains → If error loading XUL files, partially constructed, invisible window remains and causes hang on exit.
Comment 6•23 years ago
|
||
Moving Netscape owned 0.9.9 and 1.0 bugs that don't have an nsbeta1, nsbeta1+,
topembed, topembed+, Mozilla0.9.9+ or Mozilla1.0+ keyword. Please send any
questions or feedback about this to adt@netscape.com. You can search for
"Moving bugs not scheduled for a project" to quickly delete this bugmail.
Target Milestone: mozilla1.0 → mozilla1.2
Comment 7•22 years ago
|
||
Changing target milestone to 'Future' since these seem to have missed the 1.2
alpha. If you are still considering a fix for 1.2 please re-target accordingly.
Target Milestone: mozilla1.2alpha → Future
Comment 8•22 years ago
|
||
Is this still a bug?
Comment 9•21 years ago
|
||
This bug is targeted at a Mac classic platform/OS, which is no longer supported
by mozilla.org. Please re-target it to another platform/OS if this bug applies
there as well or resolve this bug.
I will resolve this bug as WONTFIX in four weeks if no action has been taken.
To filter this and similar messages out, please filter for "mac_cla_reorg".
Comment 10•21 years ago
|
||
I'm a bad owner for this bug since I no longer have access to a Mac. So I'm
dumping it on sfraser. Simon, this bug is scheduled to be resolved. It could
stand to be saved if it's still a problem, which it could be even on OS X.
Assignee: danm-moz → sfraser
Status: ASSIGNED → NEW
Comment 12•21 years ago
|
||
See also bug 229822.
Updated•16 years ago
|
Assignee: jag → nobody
Comment 13•14 years ago
|
||
no response to comment 8. => incomplete
please reopen if it can be reproduce with a current build
Status: NEW → RESOLVED
Closed: 14 years ago
QA Contact: jrgmorrison → xptoolkit.widgets
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•