In the call of the gtk_target_list_add_uri_targets
the
application/vnd.portal.filetransfer
and application/vnd.portal.files
are added even it has no point in case the uri scheme is https://
or any other than file://
for example. It also shows the warning during call of the gtk_selection_data_get_uris
on the drag data receiver side:
Gtk-WARNING **: 12:20:31.143: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Invalid transfer
For testing the Evolution can be used as source (drag a link from the email) and WAYLAND_DEBUG=1 testfileportal
can be used as target.
Offer received by the testfileportal are following:
[ 4598.811] wl_data_offer@4278190083.offer("UTF8_STRING")
[ 4598.819] wl_data_offer@4278190083.offer("COMPOUND_TEXT")
[ 4598.825] wl_data_offer@4278190083.offer("TEXT")
[ 4598.831] wl_data_offer@4278190083.offer("STRING")
[ 4598.835] wl_data_offer@4278190083.offer("text/plain;charset=utf-8")
[ 4598.840] wl_data_offer@4278190083.offer("text/plain")
[ 4598.845] wl_data_offer@4278190083.offer("text/html")
[ 4598.852] wl_data_offer@4278190083.offer("text/uri-list")
[ 4598.857] wl_data_offer@4278190083.offer("application/vnd.portal.filetransfer")
[ 4598.863] wl_data_offer@4278190083.offer("application/vnd.portal.files")
[ 4598.868] wl_data_offer@4278190083.offer("_NETSCAPE_URL")
[ 4598.873] wl_data_offer@4278190083.offer("text/plain;charset=utf-8")
[ 4598.877] wl_data_offer@4278190083.offer("UTF8_STRING")
[ 4598.883] wl_data_offer@4278190083.offer("COMPOUND_TEXT")
[ 4598.888] wl_data_offer@4278190083.offer("TEXT")
[ 4598.892] wl_data_offer@4278190083.offer("text/plain")
[ 4598.901] wl_data_offer@4278190083.offer("STRING")
[ 4598.904] wl_data_offer@4278190083.offer("text/plain;charset=utf-8")
[ 4598.909] wl_data_offer@4278190083.offer("text/plain")
[ 4598.913] wl_data_offer@4278190083.offer("text/html")
[ 4598.918] wl_data_offer@4278190083.offer("text/uri-list")
[ 4598.922] wl_data_offer@4278190083.offer("application/vnd.portal.filetransfer")
[ 4598.927] wl_data_offer@4278190083.offer("application/vnd.portal.files")
[ 4598.932] wl_data_offer@4278190083.offer("_NETSCAPE_URL")
[ 4598.974] wl_data_offer@4278190083.offer("DELETE")
gtk3-3.24.41-1.fc39.x86_64
Ah, the first try works for the testfileportal, the subsequent does not because the uris list is emptied during first try in the testfileportal. I did test for the first time the regular gtk3-widget-factory build and then the flatpak one. So no bug at all.
I'm using the testfileportal
to start the drag operation. If I simply open the gtk3-widget-factory from the gtk3-devel rpm package the drop on the file chooser button works fine.
But if I do the same for the
flatpak run --devel --command=gtk3-widget-factory org.mozilla.Firefox
(note that I'm using fedora org.mozilla.Firefox build based on f39 runtime). I get failure and following output:
(gtk3-widget-factory:2): Gtk-WARNING **: 12:59:19.373: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Invalid transfer
Does the drop on the gtk3-widget-factory works even when it's run from the flatpak (like the testcase I've mentioned above)? Or does it need any additional permission?
Does this really fix the issue like dragging file from nautilus to the file dropdown target (shown by mouse cursor)? Because it does not for me with gtk 3.24.38.
$ flatpak run --devel --command=gtk3-widget-factory org.mozilla.firefox --version
gtk3-widget-factory 3.24.38
$ flatpak run --devel --command=gtk3-widget-factory org.mozilla.firefox
Since the g_app_info_launch_uris
went to async [0] it always returns positive result (unless dbus is somehow messed up), which prevents to run g_openuri_portal_open_uri
[1] when in flatpak environment. So for example opening a directory by gtk_show_uri leads to silent failure.
[0] https://gitlab.gnome.org/GNOME/glib/-/blob/main/gio/gdesktopappinfo.c#L3221 [1] https://gitlab.gnome.org/GNOME/glib/-/blob/main/gio/gappinfo.c#L834
$ flatpak info org.mozilla.firefox
Firefox - Mozilla Firefox Web Browser
ID: org.mozilla.firefox
Ref: app/org.mozilla.firefox/x86_64/stable
Arch: x86_64
Branch: stable
Version: 88.0.1
License: MPL-2.0
Origin: flathub
...
$ flatpak info org.mozilla.Firefox
Firefox - Web Browser
ID: org.mozilla.Firefox
Ref: app/org.mozilla.Firefox/x86_64/stable
Arch: x86_64
Branch: stable
Version: 88.0.1
License: GPL-3.0+
Origin: fedora
...
$ rpm -q firefox
firefox-88.0.1-1.fc34.x86_64
How to deal with the situation? Same for the default application dialog:
gtk3-3.24.28-2.fc32.x86_64 mutter-3.36.9-1.fc32.x86_64 wayland
In case the popup does not fit to the monitor, it is moved to the adjacent monitor. If the second monitor does not contain part of the window (including shadow), the popup is not visible. The root cause is that the popup cannot be shown outside of parent window under wayland. Note this works for maximized apps because the shadow is still on the other monitor where the popup is placed.
No popup has been shown.
Screencast show it several time. Screencast_from_04-23-2021_04_24_49_PM