<html> <head> <base href="https://bugzilla.gnome.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_REOPENED " title="REOPENED - File descriptor leak in gdk_wayland_selection_request_target()" href="https://bugzilla.gnome.org/show_bug.cgi?id=751414#c11">Comment # 11</a> on <a class="bz_bug_link bz_status_REOPENED " title="REOPENED - File descriptor leak in gdk_wayland_selection_request_target()" href="https://bugzilla.gnome.org/show_bug.cgi?id=751414">bug 751414</a> from <a href="page.cgi?id=describeuser.html&login=carlosg%40gnome.org" title="Carlos Garnacho <carlosg@gnome.org>"> Carlos Garnacho</a> <pre>(In reply to Michael Catanzaro from <a href="show_bug.cgi?id=751414#c10">comment #10</a>) > We should probably try to define the expected behavior as well. I propose: > "GTK+ should not create more pipes to the destination client than the number > of MIME types it has offered." The behavior is actually imposed by X-isms in GDK/GTK+, not more than one target per selection can be on the fly, selection requests on the low-level work by 1) emitting a GdkEventSelection and 2) the affected widget calling gdk_property_change for the selection atom. Newer requests should be cancelling previous ones, which I realize we don't always do on all paths where gdk_wayland_selection_check_write() is called. More patches coming, testing appreciated, although I'll try too with your weston hack.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are on the CC list for the bug.</li> </ul> </body> </html>