Closed Bug 79022 Opened 19 years ago Closed 11 years ago
gtkmozembed focus crashes using gtk
Note Book after closing tabs
When using multi tab browsing, after closing a tab focus events cause gtk warnings, errors, and segfaults. Reproducibility: Every time. Steps to Reproduce: 1. use attached patch against TestGtkEmbedNotebook 2. run TestGtkEmbedNotebook 3. click on "mozembed2" tab. 4. wait for page to load, click in the window. (the patch makes this close the tab) 5. resize, click in, tab in/out of, pretty much do anything with the remaining tab Actual Results: Much output like: Gtk-WARNING **: invalid class type `(unknown)' in cast to `GtkObject' Gtk-WARNING **: invalid class type `(unknown)' in cast to `GtkObject' Gtk-CRITICAL **: file gtksignal.c: line 541 (gtk_signal_emit): assertion `gtk_type_is_a (GTK_OBJECT_TYPE (object), signal->object_type)' failed. Gtk-WARNING **: invalid cast from `(unknown)' to `GtkObject' Gtk-WARNING **: invalid cast from `(unknown)' to `GtkObject' Gtk-CRITICAL **: file gtksignal.c: line 541 (gtk_signal_emit): assertion `gtk_type_is_a (GTK_OBJECT_TYPE (object), signal->object_type)' failed. Eventually (or sometimes immediatly) this causes a segfault. Expected Results: App should function normally after closing a tab. Additional Information: here is a typical traceback: (gdb) bt #0 0x4014abde in gtk_mozarea_get_toplevel_focus () from /x/donut/src/mozilla/dist/lib/libgtksuperwin.so #1 0x402881d4 in gdk_input_remove () from /usr/lib/libgdk-1.2.so.0 #2 0x402882fe in gdk_add_client_message_filter () from /usr/lib/libgdk-1.2.so.0 #3 0x4028926c in gdk_wm_protocols_filter () from /usr/lib/libgdk-1.2.so.0 #4 0x40289496 in gdk_wm_protocols_filter () from /usr/lib/libgdk-1.2.so.0 #5 0x402b9328 in g_get_current_time () from /usr/lib/libglib-1.2.so.0 #6 0x402b9933 in g_get_current_time () from /usr/lib/libglib-1.2.so.0 #7 0x402b9acc in g_main_run () from /usr/lib/libglib-1.2.so.0 #8 0x401da667 in gtk_main () from /usr/lib/libgtk-1.2.so.0 #9 0x8048e49 in main () #10 0x403fd16b in __libc_start_main () from /lib/libc.so.6 Seems to affect both mozilla 0.9 branch and head. (as of 20010505) The same crash happens in Galeon cvs, Marco made this patch for TestGtkEmbedNotebook as a test case.
Whoops, didn't see the GTK Embedding Widget component first time.
Component: Embedding APIs → GTK Embedding Widget
reassigning, hope this is ok...
Assignee: adamlock → blizzard
QA Contact: mdunn → pavlov
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
I tested the patch (and other 2 guys tested too). It fixed the problem :) There is only a typo: gtk_window_remove_filter must be gdk_window_remove_filter.
Tested it myself too, works great. I hope this can get in 0.9, it would be sad to have to tell users they can use tabs as long as they don't close them :/
No, this won't go into 0.9 but I'll probably include it as a patch in my rpms.
I'm not so sure its a complete fix.. I still get some crashes related to focus.
By the way, RPMS from ftp.mozilla.org still exhibit the bug, I suppose you havent updated those yet :)
The 0.9 rpms have the patch.
I dont know Chris, if you say so but I downloaded your Redhat 6.x rpms from mozilla.org and here is the backtrace, looks exactly the same as that focus bug. Program received signal SIGSEGV, Segmentation fault. 0x4029a6dc in EmbedPrivate::GetPIDOMWindow () from /usr/moz/mozilla90/usr/lib/mozilla/../libgtkembedmoz.so #0 0x4029a6dc in EmbedPrivate::GetPIDOMWindow () from /usr/moz/mozilla90/usr/lib/mozilla/../libgtkembedmoz.so #1 0x4029a3a6 in EmbedPrivate::TopLevelFocusOut () from /usr/moz/mozilla90/usr/lib/mozilla/../libgtkembedmoz.so #2 0x4029894f in gtk_moz_embed_new () from /usr/moz/mozilla90/usr/lib/mozilla/../libgtkembedmoz.so #3 0x400b363f in gtk_marshal_NONE__NONE (object=0x864aec8, func=0x40298934 <gtk_moz_embed_new+1964>, func_data=0x85e71a0, args=0xbffff278) at gtkmarshal.c:312 #4 0x400e4428 in gtk_handlers_run (handlers=0x85d1948, signal=0xbffff224, object=0x864aec8, params=0xbffff278, after=0) at gtksignal.c:1917 #5 0x400e383f in gtk_signal_real_emit (object=0x864aec8, signal_id=165, params=0xbffff278) at gtksignal.c:1477 #6 0x400e1837 in gtk_signal_emit (object=0x864aec8, signal_id=165) at gtksignal.c:552 #7 0x402d9e39 in gtk_mozarea_get_toplevel_focus () from /usr/moz/mozilla90/usr/lib/mozilla/../libgtksuperwin.so #8 0x401632e5 in gdk_event_apply_filters (xevent=0xbffff5dc, event=0x81cc0e0, filters=0x82027c8) at gdkevents.c:950 #9 0x40163416 in gdk_event_translate (event=0x81cc0e0, xevent=0xbffff5dc) at gdkevents.c:1039 #10 0x4016438d in gdk_events_queue () at gdkevents.c:2055 current_time=0xbffff714, user_data=0x0) at gdkevents.c:2133 #12 0x40193796 in g_main_dispatch (dispatch_time=0xbffff714) at gmain.c:656 #13 0x40193da3 in g_main_iterate (block=1, dispatch=1) at gmain.c:877 #14 0x40193f4c in g_main_run (loop=0x82d6cb0) at gmain.c:935 #15 0x400b1b59 in gtk_main () at gtkmain.c:524 #16 0x8051194 in main (argc=1, argv=0xbffff814) at main.c:79 #11 0x401645be in gdk_event_dispatch (source_data=0x0,
i certainly had success with the redhat 6.x 0.9 rpms at mozilla.org galeon and i saw the error while playing with unpatched head
ok I guess this is a totally different bug, I got the same exact crash with CVS as of acouple of hours ago in SkipStone notebook mode. With the PIDOMWindow:: stuff..perhaps this is another bug?
The patch has worked for me, from Mozilla 0.9, to a CVS checkout as of Tue, Mar 15, 2001. Going to commit it?
Yeah, I will commit it soon.
r=dbaron. I'm assuming there's no chance of the reverse problem (the toplevel widget going away before the mozarea), based on some intuitive idea of what toplevel ought to mean, since I don't really know much about GTK.
If the toplevel is destroyed part of that destroy process is that all of the child widgets ( in this case the mozarea ) are destroyed and this method will be called.
Per blizzard's req. I've looked at attachment 34820 [details] [diff] [review]. It seems okay but as I have limited gdk knowledge I'm not competent to actually give it a r=.
Checked in. Maher, if you are still seeing this on the tip with this patch in please file another bug so we can try to track it down.
Yes Chris, I'm still having the same problem - Will post another bug with the traceback.
*** Bug 81395 has been marked as a duplicate of this bug. ***
This was checked in a while ago.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Gtkmozembed focus crashes using gtkNoteBook after closing tabs. Linux RedHat 7.2 Mozilla 0.9.9
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Chris, I still get the same back trace with Gtk+ 2.0 and Mozilla 1.6/GTK2 For this to happen, I just have to focus out of the container which has mozembed in it - like shading the window or opening a dialog - It does not happen immediately but eventually it does. 0x404fe64e in EmbedPrivate::GetPIDOMWindow () from /usr/lib/libgtkembedmoz.so (gdb) bt #0 0x404fe64e in EmbedPrivate::GetPIDOMWindow () from /usr/lib/libgtkembedmoz.so #1 0x404fe2cf in EmbedPrivate::TopLevelFocusOut () from /usr/lib/libgtkembedmoz.so #2 0x404fb2af in gtk_moz_embed_new () from /usr/lib/libgtkembedmoz.so #3 0x4018cc84 in _gtk_marshal_BOOLEAN__BOXED () from /usr/lib/libgtk-x11-2.0.so.0 #4 0x40435c20 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #5 0x40449c55 in g_signal_emit_by_name () from /usr/lib/libgobject-2.0.so.0 #6 0x404489ee in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #7 0x40448f14 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #8 0x4028ad17 in gtk_widget_send_expose () from /usr/lib/libgtk-x11-2.0.so.0 #9 0x40189ffa in gtk_main_do_event () from /usr/lib/libgtk-x11-2.0.so.0 #10 0x403862b5 in _gdk_events_queue () from /usr/lib/libgdk-x11-2.0.so.0 #11 0x40492a02 in unblock_source () from /usr/lib/libglib-2.0.so.0 #12 0x40493af8 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0#13 0x40493e30 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #14 0x40494473 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 #15 0x40189823 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 #16 0x0805415e in main (argc=1, argv=0xbffffad4) at main.c:162
The original problem was fixed to the reporter's satisfaction (comment 6). Other similar crashes were fixed in other bugs (comment 27). At this point any remaining problems, even if they look the same, should go in a new bug.
Status: REOPENED → RESOLVED
Closed: 19 years ago → 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.