Using self built m-i with gtk3 on Fedora 20. -Open a new empty tab. -Start dragging it to the content of the window. -Release the mouse button as to create a new window for the tab. You get the tab preview leftover on the screen. Sadly the screenshot didn't capture it. Also the console give this on stdout which seems relevant. *** BUG *** In pixman_region32_init_rect: Invalid rectangle passed Set a breakpoint on '_pixman_log_error' to debug *** BUG *** In pixman_region32_init_rect: Invalid rectangle passed Set a breakpoint on '_pixman_log_error' to debug *** BUG *** In pixman_region32_init_rect: Invalid rectangle passed Set a breakpoint on '_pixman_log_error' to debug *** BUG *** In pixman_region32_init_rect: Invalid rectangle passed Set a breakpoint on '_pixman_log_error' to debug *** BUG *** In pixman_region32_init_rect: Invalid rectangle passed Set a breakpoint on '_pixman_log_error' to debug *** BUG *** In pixman_region32_init_rect: Invalid rectangle passed Set a breakpoint on '_pixman_log_error' to debug *** BUG *** In pixman_region32_init_rect: Invalid rectangle passed Set a breakpoint on '_pixman_log_error' to debug *** BUG *** In pixman_region32_init_rect: Invalid rectangle passed Set a breakpoint on '_pixman_log_error' to debug *** BUG *** In pixman_region32_init_rect: Invalid rectangle passed Set a breakpoint on '_pixman_log_error' to debug *** BUG *** In pixman_region32_init_rect: Invalid rectangle passed Set a breakpoint on '_pixman_log_error' to debug The only way to make it disappear is to quit Firefox

It isn't just tab thumbnails, but any d&d overlay (links, images, tabs)

Yes I have seen it in other circumstances.

Does not seems to cause harm, but it doesn't work.

Yeah. After some debugging I found that gtk_drag_drop_finished() in gtk3 does launch the d&d animation by gtk_widget_add_tick_callback(). It uses two callbacks - gtk_drag_anim_tick() and gtk_drag_anim_destroy() - but no one is called thus the animation is not performed and the image/icon stays here until the application quits. It's Fedora 20 only - gtk3-3.10. Fedora 19 works well.

Happens on Gtk3 3.12 too. (F20 + copr)

Hm, this frame animation (the same as in gtk_widget_add_tick_callback()) does not work for the hidden widget, looks like a gtk bug: GdkFrameClock *frame_clock = gtk_widget_get_frame_clock(mHiddenWidget); g_signal_connect (frame_clock, "update", G_CALLBACK (frame_clock_callback), mHiddenWidget); gdk_frame_clock_begin_updating (frame_clock);

Filed as https://bugzilla.gnome.org/show_bug.cgi?id=728183 I believe it's a gtk bug. The widget has to be visible to perform the d&d.

This patch does not fix the bug (it's a bug in gtk3 toolkit) but enables toolkit d&d functions for gtk3.

This never got fixed by that patch.

And just to outline how bad it is: it is the only major bug that forced me to switch back to building for gtk2. It happen that I click drag more often than I can tolerate.

Yes, because it's a gnome bug - see https://bugzilla.gnome.org/show_bug.cgi?id=728183.

Fwiw, i've just tried 30.0b2 with gtk3, and i can reproduce the issue hub sees - no warnings on the console though. And this on OpenBSD/amd64 with gtk 3.12.0.

The warnings on the console were a red herring. Sorry about that. I guess we need to figure out a workaround. Reading the upstream it seems that it might not be fixed anytime soon.

the referenced gnome bug (https://bugzilla.gnome.org/show_bug.cgi?id=728183) is marked as RESOLVED FIXED)

Works fine on Fedora 21 with gtk3-3.14.5-1.fc21.x86_64.

works fine on the Fedora 22 package for firefox 38.0-5 and gtk3-3.16.3-1.fc22.x86_64

Shall we just bump the requirement to Gtk 3.14 when building for Gtk3? That bug made Firefox mostly unusable.

I'm okay with it, we already fixed theme bugs with Gtk 3.14.

Requiring gtk 3.14 means losing all testing coverage on elm.

(In reply to Mike Hommey [:glandium] from comment #22) > Requiring gtk 3.14 means losing all testing coverage on elm. What do you mean?

elm does gtk3 builds and tests them.

Maybe you just meant to say that you only have gtk3.4 on the test server. Well maybe we should start by upgrading this. Seriously below Gtk3 3.14 Firefox Gtk3 is UNUSABLE.

Just to make things clear: the goal is to ensure the final product is stable enough. At that point any platform still shipping Gtk 3.4 isn't interested in upgrading and therefor running the bleeding edge Gtk3 version of Firefox.

Does it actually matter what version of gtk it's built against? That is, does elm builds, built against gtk 3.4.4, exhibit the problem when run with gtk 3.14? http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/elm-linux64/latest/

It would make things clear, that's for sure. And we could also use API that are available on later versions.

(In reply to Hubert Figuiere [:hub] from comment #20) > Shall we just bump the requirement to Gtk 3.14 when building for Gtk3? That > bug made Firefox mostly unusable. Fedora 19 didn't have the bug and I assume it had GTK+ 3.8. The changes in theming APIs in about GTK+ 14 might be a reason to indicate that builds are only suitable for newer versions. I don't know when our test machines will be upgraded. For now at least we need to make things work on our test machines, which have 3.4 IIRC. Also, though, at some point we will want to drop GTK+ 2 support. When we are close to considering that, it may be worth adding workarounds for older GTK+ 3 in order to avoid needing to continue support for GTK+ 2. That's not a decision we need to make now though.

This bug can be trivially worked around by switching to GtkOffscreenWindow (https://developer.gnome.org/gtk3/stable/GtkOffscreenWindow.html) for mHiddenWidget in nsDragService; then, GDK's frame clock will continue executing for the widget, processing the tab animation even when not visible. I'll upload a patch momentarily.

This should do the trick- works for me with GTK 3.10.

DND isn't in the testsuite AFAIK, skipping try push.

GTK2 try push for good measure: https://treeherder.mozilla.org/#/jobs?repo=try&revision=6176bf7b104f