Lazilly create nsWaylandDisplay objects and remove them at Firefox quit.
nsWaylandDisplay objects should stay as global objects and don't be created/released.
The creation/removal wastes resources on server side as the wl_registry objects at nsWaylandDisplay has to be stored at server
side and can't be removed until firefox ends [1] anyway.
Also the removed nsWaylandDisplay causes crashes when display
topology changes due to the global nature of the wl_registry.
[1] https://wayland.freedesktop.org/docs/html/apa.html#protocol-spec-wl_registry
Differential Revision: https://phabricator.services.mozilla.com/D26673
This is a best effort attempt at ensuring that the adverse impact of
reformatting the entire tree over the comments would be minimal. I've used a
combination of strategies including disabling of formatting, some manual
formatting and some changes to formatting to work around some clang-format
limitations.
Differential Revision: https://phabricator.services.mozilla.com/D13371
when g_io_channel_set_encoding() fails we return invalid/uninitialized clipboardData,
so initialize clipboardData explicitly.
When SetClipboardDataOffer() is called with null aWaylandDataOffer,
delete our recent clipboard content and not throw an error message.
Differential Revision: https://phabricator.services.mozilla.com/D6039
This patch implements Drop operation on Wayland/Gtk+. That's because drop operations are part
of clipboard on Wayland and we use our own paste clipboard handler on Wayland (Bug 1282015).
Wayland drop data are provided by wl_data_device_listener, it provides us drag and drop callbacks
which we route to nsDragService module.
MozReview-Commit-ID: 9uGYPg9YF6P
When we perform copy -> paste in one Firefox process on Wayland we're locked because Wayland clipboard paste
operation just reads data from filedescriptor and does not run main event loop.
A solution is to use Gtk+ shortcut here, when clipboard selection owner is the same as data receiver.
Gtk+ then does not go through X11/Wayland but calls clipboard data getter callback directly,
which we can use on Wayland because it also does not main event loop and the operation
stays synchronous.
MozReview-Commit-ID: G8myCBUSzxb
