206.01 KB, image/png
109.63 KB, image/png
247.98 KB, image/png
3.71 KB, patch
|Details | Diff | Splinter Review|
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:42.0) Gecko/20100101 Firefox/42.0 Build ID: 20150726030217 Actual results: After Nightly migrated to GTK3 I couldn't able attach files from network share, no network shares in GTK file open dialog.
4 years ago
I don't have network shares in the GTK2 file dialog. Do you? Can you post a screenshot?
Looks like we need to remove local-only property which is default from GtkFileChooser: https://developer.gnome.org/gtk3/stable/GtkFileChooser.html
Assignee: nobody → lsalzman
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
OS: Unspecified → Linux
Hardware: Unspecified → All
(In reply to Martin Stránský from comment #4) > Looks like we need to remove local-only property which is default from > GtkFileChooser: > > https://developer.gnome.org/gtk3/stable/GtkFileChooser.html I checked the code for both GTK2 and GTK3, and both default local-only to true, nor do we actually trigger the place in our gtk nsFilePicker backend where it is set to false (filterAllowURLs is never used anywhere in the codebase). The code inside GTK2 and GTK3 itself guards those mount points with local_only checks as well. So, I can't see how network shares were ever shown at all in the gtk2 builds of Firefox. The only thing I can fathom/guess is there is some user-local config file in gtk2 that was being used to override the default? Any ideas, Martin?
This worked in gtk2 builds before because there was a fallback to map remote location to FUSE filesystem, so system IO worked well. It is mentioned there: https://developer.gnome.org/gtk3/stable/GtkFileChooser.html#gtk-file-chooser-set-local-only by: "On some systems non-native files may still be available using the native filesystem via a userspace filesystem (FUSE)." Same documentation is in GTK3, we'll try to find out why this feature has been removed from gtk3: https://bugzilla.redhat.com/show_bug.cgi?id=1262724
I don't think this issue is going to keep us from shipping GTK3. Both possible solutions (FUSE or GIO) seem like quite a bit of work.
No longer blocks: ship-gtk3
Attaching more like a workaround for this bug. AFAIK GTK staff is not willing to revert that change, see downstream bug: https://bugzilla.redhat.com/show_bug.cgi?id=1262724 Karl, could you please try to check that approach?
Comment on attachment 8671257 [details] [diff] [review] filepicker-fix.patch I don't know enough about what is happening here to give sensible feedback. Can you explain for me please? What exactly has changed in GTK? The documentation implies that gtk_file_chooser_get_filename() is safe to depend on only if local-only is true. Is there something that makes it safe with local-only false? Matthias says "The local-only property is supposed to ensure that you get a location back from the file chooser that you can use with POSIX file api." Isn't that exactly what we want? AIUI FUSE provides POSIX file API access. What distinction is he making?
Remote locations has been showed in gtk2 file dialog and when calling gtk_file_chooser_get_uri you got URI to local file, like "file:///fusemount/file.html" instead of "sftp://host/file.html", exactly as described there: https://developer.gnome.org/gtk3/stable/GtkFileChooser.html#gtk-file-chooser-get-uri This stopped working in gtk3, documentation is outdated in gtk3. GTK3 removed remote locations from file dialog when gtk_file_chooser_set_local_only is set to true (that's default). No matter if they are FUSE (so accessible by POSIX file api) or not. Only local files/locations are shown. Matthias suggestion to simply set gtk_file_chooser_set_local_only to false is not so simple, because we start to get URI like sftp://host/file.html and there's no support for this in Firefox. We would have to implement whole GIO file interface and handle a lot of stuff, like when remote locations are not mounted, store URI somewhere for resuming downloads and so.
Sorry, I've attached not updated patch, so it missed any comments what's going on. Reattaching.
Attachment #8671257 - Attachment is obsolete: true
Comment on attachment 8672492 [details] [diff] [review] filepicker-fix.patch v2 >- gchar *filename = gtk_file_chooser_get_uri(GTK_FILE_CHOOSER(file_chooser)); >- mFileURL.Assign(filename); >+ // Get local file instead of uri to remote location, ie.: >+ // sftp://something -> file:///run/user/.../gvfs/sftp:host=something... >+ // This is fallback for GTK3, GTK2 was able to show files on remote locations >+ // and provided file:/// uri for remote locations when >+ // gtk_file_chooser_set_local_only was set to true. >+ gchar *filename = gtk_file_chooser_get_filename(GTK_FILE_CHOOSER(file_chooser)); Are you expecting gtk_file_chooser_get_filename() to provide local filenames for remote files through FUSE? I doubt we can expect that to work for all remote locations?
What's new about this bug ?
Priority: -- → P4
Summary: After Nightly migrated to GTK3 I couldn't able attach files from network share → After Nightly migrated to GTK3 attaching files from network share fails
Whiteboard: [gtk-noted] → [gtk-noted], tpi:+
Hi, After investigating the problem, it's a bug in GTK+3 : https://bugzilla.gnome.org/show_bug.cgi?id=787128
(In reply to Colin Leroy from comment #15) > Hi, > > After investigating the problem, it's a bug in GTK+3 : > > https://bugzilla.gnome.org/show_bug.cgi?id=787128 https://bugzilla.gnome.org/show_bug.cgi?id=787128 is marked fixed
You need to log in before you can comment on or make changes to this bug.