- Allow async data transfer when widget.wayland.async-data-transfer.enabled static is set.
- Return early when fast track request number does not match and don't process such events.
- Use kClipboardFastIterationNum to process fast iterations.
Depends on D123609
Differential Revision: https://phabricator.services.mozilla.com/D123610
- Allow async data transfer when widget.wayland.async-data-transfer.enabled static is set.
- Return early when fast track request number does not match and don't process such events.
- Use kClipboardFastIterationNum to process fast iterations.
Depends on D123609
Differential Revision: https://phabricator.services.mozilla.com/D123610
Merge WaylandDragAndDropDataOffer and DataOffer classes to avoid potential timing issue when Drag&Drop action is set before WaylandDragAndDropDataOffer is created.
Differential Revision: https://phabricator.services.mozilla.com/D121877
We're reading clipboard data from fd in non-blocking mode and repeat when data ate not ready.
Modify reading from fd to make sure we don't wait endlessly:
- sleep 20 ms after unsuccessful before next attempt
- limit maximal reading time to 0.5 sec
Differential Revision: https://phabricator.services.mozilla.com/D120667
Firefox uses synchronized clipboard data get/set which causes issues when clipboard data is transferred in scope of Firefox
itself as getting code blocks the sending one. As a workaround X11 clipboard code runs restricted message loop (processes clipboard events only),
Wayland clipboard handler uses fast (direct) path when clipboard data is owned by Firefox and D&D code runs main loop for some limited time.
When D&D operation is used on Wayland we can't determine clipboard data owner - so we can't use the fast (direct) data transfer but we always
read data from wayland clipboard. That approach block when D&D data comes from Firefox itself.
In orded to fix that this patch does:
- Implement DataOffer::GetDataInternal() as non-blocking, i.e. fail when we can't get data from file descriptor provided by Wayland clipboard code.
- Create new thread and run DataOffer::GetDataInternal() there
- Run limited main event loop as D&D code does.
In order to make the changes possible we also need to better track wayland data offers:
- Implement DataOffer as ref counted general wayland clipboard data placeholder
- Implement WaylandDragAndDropDataOffer for D&D data events
- Track all offers in offer cache (mActiveOffers)
Differential Revision: https://phabricator.services.mozilla.com/D118577
Recently we use fast track clipboard shortcut to get clipboard data when clipboard content is owned by Firefox but
we ask Wayland compositor for clipboard content mime types.
That may lead to a bug when Firefox is faster and sets clipboard content internally but Wayland compositor does not have the content yet.
So use fast track to also get clipboard mime types.
Differential Revision: https://phabricator.services.mozilla.com/D111377
This is required to support pasting the primary selection into Firefox on compositors only
supporting the public protocol, such as KWin. Getting the selection *from* Firefox is done
via GTK and will be supported from GTK 3.24.23 on.
The public protocol, while practically identical, will replace the gtk-private one eventually.
However, support for the private one will still be needed for a while.
Note: this also updates the auto-generated gtk-primary-selection files.
Differential Revision: https://phabricator.services.mozilla.com/D91594
This is required to support pasting the primary selection into Firefox on compositors only
supporting the public protocol, such as KWin. Getting the selection *from* Firefox is done
via GTK and will be supported from GTK 3.24.23 on.
The public protocol, while practically identical, will replace the gtk-private one eventually.
However, support for the private one will still be needed for a while.
Note: this also updates the auto-generated gtk-primary-selection files.
Differential Revision: https://phabricator.services.mozilla.com/D91594
- Create nsWaylandDisplay as a ref-counted struct to avoid potential delete when a display is used.
- Don't use Mutex to access all display array operations. Use only write mutex when the array is modified / released.
- Store all wayland displays in nsTArray instead of fixed plain C array.
- Release all displays before we close Gtk display to make sure we quit before Gtk connections are closed.
Differential Revision: https://phabricator.services.mozilla.com/D89188
- Create nsWaylandDisplay as a ref-counted struct to avoid potential delete when a display is used.
- Don't use Mutex to access all display array operations. Use only write mutex when the array is modified / released.
- Store all wayland displays in nsTArray instead of fixed plain C array.
- Release all displays before we close Gtk display to make sure we quit before Gtk connections are closed.
Differential Revision: https://phabricator.services.mozilla.com/D89188
- X11 uses MOZ_GTK_DRAG_RESULT_NO_TARGET to state 'no place' for drop. Wayland does not have protocol for it and always return MOZ_GTK_DRAG_RESULT_ERROR.
To emulate X11 behaviour for tab D&D (application/x-moz-tabbrowser-tab mime) don't cancel D&D operation on Wayland for MOZ_GTK_DRAG_RESULT_ERROR
to allow to create a new tab when user drops tab outside the tab bar.
- Provide some additional loging to D&D code.
Differential Revision: https://phabricator.services.mozilla.com/D70333
--HG--
extra : moz-landing-system : lando
- Properly initialize `mSelectedDragAction` of data_offers so `GetSelectedDragAction()`
does not return random values.
- Emit a motion event on `data_offer_action`, just like GTK does, to chain up to
`nsDragService::UpdateDragAction()`
- Only advertise possible actions if we actually accept them.
- Rename some things to make them easier to understand
Differential Revision: https://phabricator.services.mozilla.com/D60853
--HG--
extra : moz-landing-system : lando
The inclusions were removed with the following very crude script and the
resulting breakage was fixed up by hand. The manual fixups did either
revert the changes done by the script, replace a generic header with a more
specific one or replace a header with a forward declaration.
find . -name "*.idl" | grep -v web-platform | grep -v third_party | while read path; do
interfaces=$(grep "^\(class\|interface\).*:.*" "$path" | cut -d' ' -f2)
if [ -n "$interfaces" ]; then
if [[ "$interfaces" == *$'\n'* ]]; then
regexp="\("
for i in $interfaces; do regexp="$regexp$i\|"; done
regexp="${regexp%%\\\|}\)"
else
regexp="$interfaces"
fi
interface=$(basename "$path")
rg -l "#include.*${interface%%.idl}.h" . | while read path2; do
hits=$(grep -v "#include.*${interface%%.idl}.h" "$path2" | grep -c "$regexp" )
if [ $hits -eq 0 ]; then
echo "Removing ${interface} from ${path2}"
grep -v "#include.*${interface%%.idl}.h" "$path2" > "$path2".tmp
mv -f "$path2".tmp "$path2"
fi
done
fi
done
Differential Revision: https://phabricator.services.mozilla.com/D55444
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
