GNOME Bugzilla – Bug 753932
document turns readonly after failed save
Last modified: 2020-11-24 09:59:34 UTC
Create a new document, save it, and in the save dialog, choose a readonly location such as /root/newfile. You get a confirmation dialog, which is somewhat confusingly worded - it talks about 'replacing', but there is nothing to replace here... anyway, choose to go ahead. Now you get an infobar informing you that saving failed. This is good. However, if you stubbornly ignore it for a couple of minutes, it goes away on its own, and... the document is now considered readonly?! That seems wrong - we tried to save to a readonly location, but that failed. It should be possible to save again, to a different location.
I have not yet looked closely, but this is probably a fall out of moving the "read-only" property to gtksourcebuffer: when the tab is focused again, gtksourceview stats the file, see that the location is not writable, notifies us, and we do not handle that case well in the state machine since we are already in a "saving failed" state. If my theory is right there are various aspect to this bug, some of them in gedit some of them in gtksourceview: - we set the file location associated to the document when starting a save and as long as the infobar is shown we do not unset it since it may allow you to try again; however we should be aware that is a "tentative" location and if the file save failed we should not be trying to stat and check for modified/readonly - we need to handle readonly notification in a more robust way when we are in an error state - we need to improve the heuristic that shows the confirmation dialog in the save file chooser: if we can confirm the file is there but not writable we should show the current message, but if we do not have access to the dir at all we should use a more generic sentence
Also, the info bar about network unavailability was not done right. When _gedit_tab_set_network_available() is called it can hide a completely different info bar. Info bars and state in GeditTab should be re-worked, to allow multiple info bars, and an info bar action should not be able to close another info bar.
About the heuristic, I think it should be gtk to check that /root/ is not accessible before showing the confirmation-dialog: I filed a patch in https://bugzilla.gnome.org/show_bug.cgi?id=753969 I also think we should move the check for read-only in gtk itself instead of doing it gedit
Mass-closing of all gedit bugzilla tickets. Special "code" to find again all those gedit bugzilla tickets that were open before the mass-closing: 2bfe1b0590a78457e1f1a6a90fb975f5878cb60064ccfe1d7db76ca0da52f0f3 By searching the above sha256sum in bugzilla, the gedit contributors can find again the tickets. We may be interested to do so when we work on a specific area of the code, to at least know the known problems and possible enhancements. We do this mass-closing because bugzilla.gnome.org is being replaced by gitlab.gnome.org.