<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#c21">Comment # 21</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=mcatanzaro%40gnome.org" title="Michael Catanzaro <mcatanzaro@gnome.org>"> Michael Catanzaro</a> <pre>I confirm this bug is fixed when I apply these five patches. Great, thanks! (In reply to Carlos Garnacho from <a href="show_bug.cgi?id=751414#c16">comment #16</a>) > Yeah, that'd be one way to work around the "1 request on the fly" > limitation, is it too much of a change to?: > > * forward all mimetypes to the other process over internal IPC > * In the other process, pick one and tell about it to the original process > * call wl_data_offer_receive on that one, pass the fd. > * In the other process, read() and close If that would work it would have been the first thing to try, but Chrome expects the data to already be present before it deciding which type of data to pick, unfortunately. > TBH I wonder how often does the web process end up using more than one > mimetype, probably never? Probably. > > Do you consider this a deficiency in GTK+ worth changing eventually? (But if > > so, we'd need a plan to prevent the drag destination from causing clients to > > use arbitrarily many fds.) Or would it be better to change the Wayland > > protocol documentation to indicate that wl_data_offer_receive() should not > > be used multiple times in a row without first closing the > > previously-received pipe? > > Selections and DnD APIs are indeed calling for a redesign, probably lowering > everything to GDK and making it all GAsyncResult driven (sounds like a 4.x > target though). > > However, on X11 the limitation is at the guts of the selections mechanism, > so it's unclear to me whether we can safely support this across backends. To be clear, the problems I see are: * If GTK+ were to allow handling multiple data transfers at once in the future, there would need to be policy either in GTK+ or in the compositor to ensure that the drop target cannot initiate an arbitrary number of simultaneous transfers. * If GTK+ continues to not handle multiple data transfers at once, it's arguably not implementing its end of the protocol properly. Since it works with the reference Weston client, I would expect it to work with GTK+ as well. But if there was upstream documentation to say "don't expect this to work" (the simplest solution, possibly the best solution) then there would be no problem. Whatever; I know now not to expect it to work. :)</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are on the CC list for the bug.</li> </ul> </body> </html>