The filechooser dialog in gtk2 contained all remote location even when gtk_file_chooser_set_local_only(TRUE) was set. This is documented by (see [1]): On some systems non-native files may still be available using the native filesystem via a userspace filesystem (FUSE). Same documentation is in gtk3 [2], but remote locations are missing in gtk3 filechooser dialog now. This cause that Firefox users are unable to open/save from/to remote locations (upstream bug [3]). Fixing that on Mozilla's codebase by setting gtk_file_chooser_set_local_only(FALSE) and implementing GIOFile interface is non-trivial task and that would require a lot of effort. [1] https://developer.gnome.org/gtk2/stable/GtkFileChooser.html#gtk-file-chooser-set-local-only [2] https://developer.gnome.org/gtk3/stable/GtkFileChooser.html#gtk-file-chooser-set-local-only [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1187870
So any progress if this issue is going to be reverted in gtk3?
I don't believe this: setting gtk_file_chooser_set_local_only (FALSE) [...] is non-trivial And no, I have no intention to change the gtk filechooser to ignore local-only.
Mathias, I had a discussion with firefox guys a few days ago, and I understood it makes sense for them. The things is they only can handle "file:///" schemas, but for them is good if FUSE throug gvfs can emulate "file:///" schemas for other types of filesystem like remote ones. Seems the local-only property of gtk2 fits perfectly their use case. As far as I can see we are not using local-only internally, so that makes me wonder it was originally implemented for Firefox maybe? Maybe a better name for how the gtk2 property was working is "native-only". The code also makes hints about that, i.e. gtkfilechooserbutton makes decisions between adding a row or not using _gtk_file_has_native_path which says "don't use g_file_is_native since we want to support fuse paths if available". So far the complain is only about the sidebar, probably a regression introduced by me when reimplemented it misunderstanding the "local-only" property. No changes in the file chooser are needed. So in conclusion, I would either match what gtk2 was doing on the sidebar or add a new property like "show-no-native-locations" or something like that.
(In reply to Carlos Soriano from comment #3) > Mathias, > > I had a discussion with firefox guys a few days ago, and I understood it > makes sense for them. > > The things is they only can handle "file:///" schemas, but for them is good > if FUSE throug gvfs can emulate "file:///" schemas for other types of > filesystem like remote ones. > > Seems the local-only property of gtk2 fits perfectly their use case. As far > as I can see we are not using local-only internally, so that makes me wonder > it was originally implemented for Firefox maybe? No it wasn't. > Maybe a better name for how > the gtk2 property was working is "native-only". > The code also makes hints about that, i.e. gtkfilechooserbutton makes > decisions between adding a row or not using _gtk_file_has_native_path which > says "don't use g_file_is_native since we want to support fuse paths if > available". 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. > So far the complain is only about the sidebar, probably a regression > introduced by me when reimplemented it misunderstanding the "local-only" > property. No changes in the file chooser are needed. Changes in the places sidebar _are_ changes in the file chooser.
Last point I forgot to make: comparison to the gtk2 file chooser is less relevant than comparison to the file chooser in 3.14 or 3.16, at this point.
(In reply to Matthias Clasen from comment #2) > I don't believe this: > > setting gtk_file_chooser_set_local_only (FALSE) [...] is non-trivial > > And no, I have no intention to change the gtk filechooser to ignore > local-only. It is non-trivial, because Firefox is using standard POSIX function to operate with files, it does not implement any stuff from GIO file handling. To support GIO file handling means a lot of code change, you can't simply replace fread by g_file_read, there's unexpected events like remote location is not mounted. Also file operations with remote locations needs to be moved to separate thread, to avoid UI lockup because of slow network and other stuff you're more aware of that I am.
If you are not willing to revert this change, fix the documentation: https://developer.gnome.org/gtk3/stable/GtkFileChooser.html#gtk-file-chooser-get-uri https://developer.gnome.org/gtk3/stable/GtkFileChooser.html#gtk-file-chooser-set-local-only
(In reply to Matthias Clasen from comment #4) > 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. That sounds useful. Wasn't that always the intention, though? That seems consistent with the documentation indicating that selected files will be available through gtk_file_chooser_get_filename(). How does what FUSE provides differ from the POSIX file API?
(In reply to Karl Tomlinson from comment #8) > How does what FUSE provides differ from the POSIX file API? I don't think fuse guarantees that you can mmap the file, e.g.
(In reply to Matthias Clasen from comment #9) > (In reply to Karl Tomlinson from comment #8) > > > How does what FUSE provides differ from the POSIX file API? > > I don't think fuse guarantees that you can mmap the file, e.g. I don't have problems with mmap files located on FUSE on recent kernel nor can find any issues connected with mmap and FUSE on the Internet. Could you please be more specific what is broken?
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
This message is a reminder that Fedora 24 is nearing its end of life. Approximately 2 (two) weeks from now Fedora will stop maintaining and issuing updates for Fedora 24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '24'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 24 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Still not solved in F26 and Rawhide
This bug appears to have been reported against 'rawhide' during the Fedora 27 development cycle. Changing version to '27'.
Can confirm that this bug is still present in F26. Very annoying. User experience is very bad when working with shares.
This message is a reminder that Fedora 27 is nearing its end of life. On 2018-Nov-30 Fedora will stop maintaining and issuing updates for Fedora 27. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '27'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 27 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This bug appears to have been reported against 'rawhide' during the Fedora 30 development cycle. Changing version to '30.
This message is a reminder that Fedora 30 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 30 on 2020-05-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '30'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 30 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 30 changed to end-of-life (EOL) status on 2020-05-26. Fedora 30 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.