Seems to happen when more than one flash-plugin instance appears on the page.

Happens only when MOZ_X_SYNC is unset and a page with the plugin is closed. Can be reproduced with any plugin (flash, vlc). Some hint:

(firefox:10896): Gtk-WARNING **: GtkSocket 0x7fffd080a850 is mapped but visible=1 child_visible=1 parent MozContainer 0x7fffe513e220 mapped=0

[20536] ###!!! ABORT: X_UnmapWindow: BadWindow (invalid Window parameter);

May be related to https://bugzilla.mozilla.org/show_bug.cgi?id=540114#c10

Looks like XSynchronize(display, True); helps here, to sync the unmap/destroy request.

It looks like the situation is an opposite to the one in mozbz#540114. The gdk still thinks it has the x window attached to GtkPlug, but the x window is already deleted.

The problem is that main Firefox process still uses already deleted GtkPlug and its Window:

plugin-container (flash-plugin) process:

----------------------------------------
AnswerNPP_Destroy() GtkSocket GdkWindow = 0x7fffef5cc360, GtkSocket x11 xid = 0x400052a
AnswerNPP_Destroy()  GtkPlug GdkWindow = 0x7fffef5cc480, x11 xid = 0x3e00003

Call NPP_Destroy() to flash-plugin

AnswerNPP_Destroy() GtkSocket GdkWindow = 0x7fffef5cc360, GtkSocket x11 xid = 0x400052a
AnswerNPP_Destroy()  GtkPlug GdkWindow = (nil), x11 xid = (nil)
----------------------------------------

So the GtkPlug and its X window has been removed. But main process (Firefox) still has the GtkPlug connected to GtkSocket after that:

----------------------------------------
socket_unrealize_cb(), GtkSocketWidget=0x7fffce5ee690, socket GdkX11Window = 0x7fffcff72300, socket x11 xid = 0x400052a
socket_unrealize_cb(), plug GdkX11Window = 0x7fffcff72540, plug x11 xid = 0x3e00003
----------------------------------------

Which is incorrect and causes:
ABORT: X_UnmapWindow: BadWindow (invalid Window parameter); 8 requests ago; id=0x3e00003

Note: It's mixed gtk3/gtk2 scenario, where Gtk3 is GtkSocket and Gtk2 is GtkPlug.

It looks like a some race-condition. Works fine when XSynchronization is enabled in main process (Firefox with GtkSocket). Also works when it's debugged step by step in gdb.

So, I've investigated this a bit, here's what I think happens:

(0) Firefox does the bad XSetInputFocus call. IN that case I can happily ignore this bug and blame it on Firefox. But let's assume the likely case that GDK is the culprit.

(1) GDK itself does call XSetInputFocus (the function causing the X error) only in two place:
https://git.gnome.org/browse/gtk+/tree/gdk/x11/gdkwindow-x11.c?id=3.10.0#n2260
https://git.gnome.org/browse/gtk+/tree/gdk/x11/gdkdisplay-x11.c?id=3.10.0#n1236

(2) GDK protects both these calls by an error trap (with an explanation of why this is necessary).

(3) Error traps were redesigned for GTK3. Instead of requiring an XSync() call, GDK keeps track of which X requests were called while inside a trap and if an error comes in, GDK's default X error handler discards it.

(4) Firefox sets its own error handler, so the GDK handler doesn't run.

(5) The Firefox error handler doesn't know that the error was trapped and should be just ignored, because only the GDK error handler would know that.

The easiest fix from my POV would be to not add a custom error handler in Firefox. Is there a good reason for why Firefox overrides the X error handler?

Thanks for the update. Does that also apply to scenario from comments 7 - 9? 

I can't reproduce the XSetInputFocus but the X_UnmapWindow: BadWindow fault is 100% reproductible, happens when I open and close any web page with flash plug-in. I can provide you testcase and test package for that too.

Please also note the sync aspect - none of the bugs is shown when XSynchronization is enabled. Actually I can't find any single point of failure.

(In reply to Benjamin Otte from comment #10)
> The easiest fix from my POV would be to not add a custom error handler in
> Firefox. Is there a good reason for why Firefox overrides the X error
> handler?

I have no idea why Firefox uses the custom X error handler. But I can confirm the error does not show when it's removed from the Firefox main process.

(In reply to Martin Stransky from comment #13)
> I have no idea why Firefox uses the custom X error handler. But I can
> confirm the error does not show when it's removed from the Firefox main
> process.

The custom X11 handler seems to be used for automated crash reporting (something like ABRT in Fedora). All crashes are uploaded at mozilla crash server.

Benjamin, mozilla uses gdk_error_trap_push()/gdk_error_trap_pop() combo in Gtk2 Firefox. Do I need to update it for the Gtk3 code? 

And can be the X11 firefox error handler registered after the gdk one? Firefox needs that for the custom crash reporting.

Thanks!

Benjamin, the X failure vanishes when the Gtk3 GtkSocked destroy callback looks like:

static void
socket_deleted_cb(GtkWidget *widget, GtkWidget **widget_pointer)
{
  gdk_error_trap_push();
  gtk_widget_destroyed(widget, widget_pointer);
  gdk_error_trap_pop();
}

Does Gtk2 have a different windnow/error handling?

Yes, GTK3 has gdk_error_trap_pop_unlocked() that is the cause of your problems. I believe gdk_error_trap_pop() still works as in GTK2 so sprinkling it in the code will help against certain bugs.

And why does Mozilla need the abort handler in the X11 handler? Isn't it catching the error when GDK calls g_error() with its default crash handler?

GDK calls XSetErrorHandler again each time gdk_x11_display_error_trap_push is
called [1], apparently to deal with the case of apps installing their own error
handler, but then, if using _pop_ignored(), restores the app's error handler
before the error has been received [2].

Xlib error handling is hard.  I haven't even thought how to make things work
with threads using the same display.  Perhaps using Display::async_handlers as
in gdkasync.c is useful.

[1] https://git.gnome.org/browse/gtk+/tree/gdk/x11/gdkdisplay-x11.c?id=3.10.7#n2596
[2] https://git.gnome.org/browse/gtk+/tree/gdk/x11/gdkdisplay-x11.c?id=3.10.7#n2669

It looks to me like GDK is not achieving what it is trying to achieve, which would mean there is a GDK bug here.

Let's trace it upstream - https://bugzilla.mozilla.org/show_bug.cgi?id=968196

The problems described in comment 13 were reported in https://bugzilla.gnome.org/show_bug.cgi?id=629608#c8, but no solution was found.