Opened 16 years ago
Closed 11 years ago
#2814 closed bug (invalid)
[Firefox] crash if you try to close it from deskbar
Reported by: | diver | Owned by: | axeld |
---|---|---|---|
Priority: | normal | Milestone: | R1 |
Component: | - General | Version: | R1/Development |
Keywords: | Cc: | tqh | |
Blocked By: | Blocking: | ||
Platform: | All |
Description
Attachments (1)
Change History (14)
by , 16 years ago
Attachment: | firefox_bt.png added |
---|
comment:1 by , 16 years ago
This might be both a Haiku and Firefox bug. Firefox because trying to do stuff to a window that's closing (it's because of mapping between single thread in firefox to BWindows threads) and maybe Haiku because not handling correct while closing internally either.
Some appserver / BWindow guy around to look at bt?
comment:2 by , 16 years ago
All what BWindow::Frame() does is:
return fFrame;
So it looks like the window is already gone, or the window pointer is invalid. While Haiku might do something differently than BeOS on shutdown (although I doubt it), I would start investigating on the Firefox side of things here.
comment:4 by , 16 years ago
I would say it's still of interest for Haiku because Firefox is supposed to be the standard browser, and it would be nice if that one works good with the alpha.
Anyway, I don't remember having seen this bug in the past, so maybe it's helpful to see when it started. This could then either point to a bug in Haiku after all, or give you a good idea why this change had such an impact on Firefox.
comment:5 by , 16 years ago
This is a case that is hard to test as it relies on unhandled requests exist in messages to the gui processing thread on Mozilla side after it has gotten a destroy message already and before it has been destroyed. I do understand why/how/what to check and fix so it's not hard to fix. It's just hard to detect/test.
As a bug, sure you can keep it, but as it isn't synced with builds or versions it is only a reminder to you to include the right Firefox if or when you do :)
comment:6 by , 16 years ago
I do think this behavior has been present for a long time, probably as long as Haiku can run Firefox. It also happens when you shut down the system and Firefox is still running. The same problem was present in *some* versions of Firefox on ZETA as well. Sometimes it only canceled the shutdown process, but sometimes it would crash. If the very same version does work on ZETA though, it may still be worth investigating if this is a Haiku problem after all, or at least a different behavior that may also affect other apps. That being said, I do think Firefox needs some fixes in this regard, quitting it from Deskbar or during shutdown was always flaky for me and only worked properly in some versions, and then again not so good in newer versions...
comment:7 by , 16 years ago
Those are different problems internally in Firefox, I wonder if we only fixed it in firefox 3 trunk when we still could build that or it just has gone back to broken.
comment:8 by , 16 years ago
Btw, it's always good if you bugreport things at http://bugzilla.mozilla.org nobody does and my memory is short and faulty.
comment:10 by , 15 years ago
Version: | R1/pre-alpha1 → R1/Development |
---|
comment:11 by , 14 years ago
Can't reproduce original back trace, but it still crashes in hrev38300 with two others:
Thread 3843 caused an exception: Segment violation [...] [Switching to team /boot/apps/BeZillaBrowser/BeZillaBrowser (3842) thread Mozilla XUL BApplication (3843)] 0x019e895f in BList::ItemAtFast () from /boot/system/lib/libbe.so (gdb) bt #0 0x019e895f in BList::ItemAtFast () from /boot/system/lib/libbe.so #1 0x01980c4a in BWindow::~BWindow () from /boot/system/lib/libbe.so #2 0x018b7f35 in BLooper::Quit () from /boot/system/lib/libbe.so #3 0x01981396 in BWindow::Quit () from /boot/system/lib/libbe.so #4 0x018afb94 in BApplication::_WindowQuitLoop () from /boot/system/lib/libbe.so #5 0x018afbeb in BApplication::_QuitAllWindows () from /boot/system/lib/libbe.so #6 0x018ad435 in BApplication::QuitRequested () from /boot/system/lib/libbe.so #7 0x018b951c in BLooper::_QuitRequested () from /boot/system/lib/libbe.so #8 0x018b7aee in BLooper::DispatchMessage () from /boot/system/lib/libbe.so #9 0x018ae7a9 in BApplication::DispatchMessage () from /boot/system/lib/libbe.so #10 0x018b9471 in BLooper::task_looper () from /boot/system/lib/libbe.so #11 0x018ad2e9 in BApplication::Run () from /boot/system/lib/libbe.so #12 0x006b0ae2 in nsBeOSApp::Main () #13 0x01abc036 in thread_entry () from /boot/system/lib/libroot.so #14 0x7003ffec in ?? () (gdb)
Thread 3905 caused an exception: Segment violation [...] [Switching to team /boot/apps/BeZillaBrowser/BeZillaBrowser (3904) thread Mozilla XUL BApplication (3905)] 0x01980230 in BWindow::Shortcut::~Shortcut () from /boot/system/lib/libbe.so (gdb) bt #0 0x01980230 in BWindow::Shortcut::~Shortcut () from /boot/system/lib/libbe.so #1 0x01980c5c in BWindow::~BWindow () from /boot/system/lib/libbe.so #2 0x018b7f35 in BLooper::Quit () from /boot/system/lib/libbe.so #3 0x01981396 in BWindow::Quit () from /boot/system/lib/libbe.so #4 0x018afb94 in BApplication::_WindowQuitLoop () from /boot/system/lib/libbe.so #5 0x018afbeb in BApplication::_QuitAllWindows () from /boot/system/lib/libbe.so #6 0x018ad435 in BApplication::QuitRequested () from /boot/system/lib/libbe.so #7 0x018b951c in BLooper::_QuitRequested () from /boot/system/lib/libbe.so #8 0x018b7aee in BLooper::DispatchMessage () from /boot/system/lib/libbe.so #9 0x018ae7a9 in BApplication::DispatchMessage () from /boot/system/lib/libbe.so #10 0x018b9471 in BLooper::task_looper () from /boot/system/lib/libbe.so #11 0x018ad2e9 in BApplication::Run () from /boot/system/lib/libbe.so #12 0x006b0ae2 in nsBeOSApp::Main () #13 0x01abc036 in thread_entry () from /boot/system/lib/libroot.so #14 0x7003ffec in ?? () (gdb)
comment:13 by , 11 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
Most likely it's a bug in BeZilla port. Closing.
back trace