forked from mirrors/gecko-dev
Bug 1885400 Don't use filetransfer portal for the remote content; r=stransky
The targets vnd.portal.filetransfer and vnd.portal.files usually contains the numeric value data associated with the file transfer portal. In case the dragged data is non-local file - like https link, the vnd.portal.files target could also be send by the drag source application and it contains https uri. The gtk_selection_data_get_uris call fails and cause delay and wrong data to be received. This needs to be fixed by upstream, meanwhile introducing this workaround to mitigate regression. See: https://gitlab.gnome.org/GNOME/gtk/-/issues/6563 Differential Revision: https://phabricator.services.mozilla.com/D205717
This commit is contained in:
parent
2bd7572f35
commit
fe347d24f2
1 changed files with 42 additions and 4 deletions
|
|
@ -1216,19 +1216,57 @@ void nsDragService::TargetDataReceived(GtkWidget* aWidget,
|
|||
GdkAtom target = gtk_selection_data_get_target(aSelectionData);
|
||||
GUniquePtr<gchar> name(gdk_atom_name(target));
|
||||
nsDependentCString flavor(name.get());
|
||||
|
||||
if (gtk_targets_include_uri(&target, 1)) {
|
||||
GUniquePtr<gchar*> uris(gtk_selection_data_get_uris(aSelectionData));
|
||||
// For the vnd.portal.filetransfer and vnd.portal.files we receive numeric
|
||||
// id when it's a local file. The numeric id is then used by
|
||||
// gtk_selection_data_get_uris implementation to get the actual file
|
||||
// available in the flatpak environment.
|
||||
//
|
||||
// However due to GTK implementation also for example the uris like https
|
||||
// are also provided by the vnd.portal.filetransfer target. In this case the
|
||||
// call gtk_selection_data_get_uris fails. This is a bug in the gtk.
|
||||
// To workaround it we try to create the valid uri and only if we fail
|
||||
// we try to use the gtk_selection_data_get_uris. We ignore the valid uris
|
||||
// for the vnd.portal.file* targets.
|
||||
// See: https://gitlab.gnome.org/GNOME/gtk/-/issues/6563
|
||||
if (flavor.Equals(gPortalFile) || flavor.Equals(gPortalFileTransfer)) {
|
||||
const guchar* data = gtk_selection_data_get_data(aSelectionData);
|
||||
if (!data || data[0] == '\0') {
|
||||
LOGDRAGSERVICE(" Empty data!\n");
|
||||
return;
|
||||
}
|
||||
nsCOMPtr<nsIURI> sourceURI;
|
||||
nsresult rv =
|
||||
NS_NewURI(getter_AddRefs(sourceURI), (const gchar*)data, nullptr);
|
||||
if (NS_FAILED(rv)) {
|
||||
// We're unable to get the URI, we'll use the
|
||||
// gtk_selection_data_get_uris to get the actual file location
|
||||
// accessible from the Firefox runtime.
|
||||
GUniquePtr<gchar*> uris(gtk_selection_data_get_uris(aSelectionData));
|
||||
uris.swap(mTargetDragUris);
|
||||
} else {
|
||||
LOGDRAGSERVICE(
|
||||
" got valid uri for MIME %s - this is bug in GTK - expected "
|
||||
"numeric value for portal, got %s\n",
|
||||
flavor.get(), data);
|
||||
return;
|
||||
}
|
||||
|
||||
} else {
|
||||
GUniquePtr<gchar*> uris(gtk_selection_data_get_uris(aSelectionData));
|
||||
uris.swap(mTargetDragUris);
|
||||
}
|
||||
#ifdef MOZ_LOGGING
|
||||
if (MOZ_LOG_TEST(gWidgetDragLog, mozilla::LogLevel::Debug)) {
|
||||
gchar** uri = uris.get();
|
||||
gchar** uri = mTargetDragUris.get();
|
||||
while (uri && *uri) {
|
||||
LOGDRAGSERVICE(" got uri %s, MIME %s", *uri, flavor.get());
|
||||
uri++;
|
||||
}
|
||||
}
|
||||
|
||||
#endif
|
||||
uris.swap(mTargetDragUris);
|
||||
|
||||
if (mTargetDragUris) {
|
||||
mCachedUris.InsertOrUpdate(
|
||||
flavor, GUniquePtr<gchar*>(g_strdupv(mTargetDragUris.get())));
|
||||
|
|
|
|||
Loading…
Reference in a new issue