Closed
Bug 7792
Opened 25 years ago
Closed 25 years ago
Problem closing windows using toolkit
Categories
(Core :: XUL, defect, P3)
Core
XUL
Tracking
()
VERIFIED
WONTFIX
M13
People
(Reporter: davidm, Assigned: danm.moz)
References
()
Details
Attachments
(1 file)
(deleted),
text/html
|
Details |
The following js
function BrowserClose()
{
dump("BrowserClose\n");
// Currently window.close doesn't work unless the window was opened from JS
// window.close();
core = XPAppCoresManager.Find("toolkitCore");
if ( !core ) {
core = new ToolkitCore();
if ( core ) {
core.Init("toolkitCore");
}
}
if ( core ) {
core.CloseWindow( window );
} else {
dump("Error; can't create toolkitCore\n");
}
}
does not work if more than 1 browser window has been created. Depending on the
platform the symptoms differ. On Linux/Windows the content is destroyed but the
the window sticks around. If you do anything that access the content ( select a
menu, click on a link ) you crash. On the mac the window may or may not close.
You might hang right away or everything might appear to be fine. If it appears
fine when I open another browser window I get JS errors complaining about the
memory pool. I assume we have some reference counting/ownership issues that need
to be worked out
Updated•25 years ago
|
Assignee: trudelle → danm
Comment 1•25 years ago
|
||
You assume correctly, DanM has a fresh new slew of them to deal with every
week. reassigning to him.
Updated•25 years ago
|
Target Milestone: M7
Comment 2•25 years ago
|
||
targetting m7
Updated•25 years ago
|
Target Milestone: M7 → M8
Comment 3•25 years ago
|
||
moving to m8. danm, let me know if you get somthing..
refcount balancing and who knows what else have fixed this problem on Mac and Linux.
Still broken on Windows.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Window refcount was incremented but never decremented while traversing menus. Fix that, and the window
can once again close itself. Meanwhile, had to add another set of inc/dec refcounts because the window,
now that it actually deletes itself, was deleting too early and crashing. This is all windows-specific.
Whiteboard: [7.19.1999]waiting for input
added html testcase to url containing the browser close function. (will attatch
later)
steps to run test:
1. launch apprunner(to get window1) and open 2 new windows(window2 and window3)
2. load the above url (or the attatchment) in each window.
3. click the 'close' button in window2.
4. click the 'close' button in window1.
5. click the 'close' button in window3.
works perfectly on:
1999-07-19-08 MacOS 8.51 (Apprunner)
1999-07-19-08 WinNT 4.0 sp4 (Apprunner)
(all windows close with no noise in the console)
flaky on:
1999-07-19-08 RedHat Linux 5.2 (GNOME/enlightenment)
actual behavior:
at least once (seemingly randomly) the closing of a window will yelid
several warnings like this (all the same one):
Gtk-CRITICAL **: file gtkcontainer.c: line 717 (gtk_container_remove):
assertion `widget->parent == GTK_WIDGET (container)' failed.
then you might get groups of these upon closing a later window:
Gtk-WARNING **: invalid cast from `(unknown)' to `GtkWidget'
Gtk-CRITICAL **: file gtkcontainer.c: line 716 (gtk_container_remove):
assertion `GTK_IS_WIDGET (widget)' failed.
Gtk-CRITICAL **: file gtkcontainer.c: line 717 (gtk_container_remove):
assertion `widget->parent == GTK_WIDGET (container)' failed.
i presume the problem is with menus.
dna, shall i open a new bug on this, or is it related enough to reopen?
Whiteboard: [7.19.1999]waiting for input → [7.26.1999]waiting for input
Comment 9•25 years ago
|
||
Sorry for spam, re-assigning phillip's QA contact XPToolkit/XPWidget bugs to
claudius due to restructure
Updated•25 years ago
|
Status: RESOLVED → REOPENED
Comment 10•25 years ago
|
||
REOPENING due to REGRESSION. following the steps out lined in phillip's comments from
07/19/1999 this bug reproduced on all platforms. The behavior has changed and therefore
may represent a different bug or uncompleted work, however this used to work on 2of3
platforms and now fails on all three.
Following the steps to reproduce always yeilds a console messgae of:
MyBrowserClose
JavaScript Error: ReferenceError: XPAppXoresManager is not defined
URL: http://wetnap.mcom.com/seamonkey/bugs/bug7792.html
LineNo: 13
On all platforms with the 1999102909 builds
Comment 11•25 years ago
|
||
Clearing FIXED resolution due to reopen. trudelle, you'll need to resert
milesone since M8 is way over :-)
Updated•25 years ago
|
OS: Mac System 8.5 → All
Target Milestone: M8 → M12
Comment 12•25 years ago
|
||
targetting m12
Comment 13•25 years ago
|
||
Mass-moving non-PDT+ bugs to M13
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → WONTFIX
Whiteboard: [7.26.1999]waiting for input
Assignee | ||
Comment 14•25 years ago
|
||
Hmmmmmm. As far as I know, today no window closing problems remain. The toolkit core
isn't doing anything tricky, so it should work. That would suggest a "works for me" resolution.
The real issue though, here half a year after this report was filed, is that the toolkit core is a
hoary deprecated thing. You shouldn't be using it to close windows any more. If anyone is, and
there are problems, they should instead use the standard JS window.close(). Marking this
"won't fix." If there were problems using window.close() method, that would be a very bothersome
new bug.
Comment 15•25 years ago
|
||
after careful consideration, marking this bug VERIFIED
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•