-
Notifications
You must be signed in to change notification settings - Fork 91
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changing File from Desktop leads to conflict in browser, even if browser was not doing any changes. #4078
Comments
What exactly do you mean with conflict? As the message suggests, changes were done outside of the editor, and you see the document as it was loaded, and how it is currently. I would not call it a bug at all, but room for improvement. Also, a sudden reload of the file can lead to confusion (jumping cursors) and undesired changes, potentially unnoticed, when you were about to type, right when the reload happened. |
cc @nextcloud/designers for UX impact |
With Conflict I am referring to the technical term that is commonly used when a common document A is modified by two parties B and C and the changes need to be consolidated into a new state. There are types of changes that cannot be automatically resolved and need human intervention. But when a document is modified only by one Party, its a linear history and that should not create a conflict (or a confusing warning for the users). And I don't think the point that the content could change under your eyes is really valid, because this can already happen when someone else is modifying the document using a different browser instance. (and this is actually a great feature because it allows collaborative editing) I did not have a look in how far the server requests differ when the document is edited in another browser VS. In the Desktop app. But one possible strategy would be that the when the document changes the server send a DIFF instead of the full file and if that DIFF can be cleanly applied it is applied like any other streamed change. Only if that DIFF cannot be applied without conflicts, then and only then this warning should be shown. I would estimate that using this strategy this interrupting error message could be reduced by 50-90% depending on the type of work flow the users have. |
But there is no need to reinvent the wheel there. All these issues are relatively common and have been solved for example in the git program that also this repository is using... |
Not exactly, as you are aware when someone else is having the document open in text, and you also see the guest's cursor position. |
this really looks to me as a bug : when you share the .md file in nextcloud, in some way the text app make it visible online, which is great, but if i modify it with any other app than the online text editor (and maybe the markdown editor ? i didn't try, didn't enabled this app) it will go crazy, the changes do not show untill i connect to my account and validate that there is no conflict, and the desktop nextcloud app cannot sync the document anymore, creating a multitude of conflict messages so this problem prevents me to modify my document outside the online text app, hence : bug that's weird from an ux point of view : this document is a md document in my folders, i should be abble to modify it offline without conflict since i'm the ony one doing so |
Yes, thats right. I guess that it won't be possible to implement this if a change is coming from external.
Thanks for putting it in different words, not sure if I explained it so good before.. |
https://github.com/nextcloud/text/blob/c967d0127151da5a64b770778c097a52e8b3c69a/lib/Service/ApiService.php#LL245C1-L252C5 |
As discussed internally today, we'd like to stress that this behaviour right now is by design, so changes to this are indeed improvements, and we also agree with the sentiment here. When implementing the change, and text does reload the document without user interaction in the scenario outlined, there must be also some sort of visual feedball/notifier for the users to be not surprised by sudden changed. It could be a popup notification for instance. |
allright, i respect your position and all the great work you do, but there is something weird here : if i want to share a link to a .md document, which is a basic nextcloud feature (sharing links to documents), even if i don't want it to be preview in the browser, even if i don't want to use the text app on this file, i cannot : as soon as i share the document the text app is automatically involved (i need to verify that), and the document will not be updated when i change it locally, plus it will create multitude of conflicts messages in my local nextcloud desktop app, and break a standard nextcloud feature my only option here (i need to verify that on my computer later) is to disable the text app alltogether. otherwise it prevents me from using and sharing .md files. unless i can tell it not to 'take care' of one specific file ? that would be a bad workaround still, but feasable i don't see how it is not a bug : i install the text app and then another feature (sharing and syncing a .md file) is broken or did i not understood something here ? i have to take into account the fact that my server is poorly configured ;) |
Oh woah, but why didn't it load the most recent server-side version first? I'm confused what "current" means in this context.
+1. In English the left side says "Use current version" and "Use the saved version". The one on the right seems to usually be the safe choice. Also, is this a dup of #2388 ? Related: https://help.nextcloud.com/t/text-document-current-vs-saved-version/151600 |
To me this "feature" sounds like a "simple" workaround to avoid a more complex solution. Did a customer request this "feature"? ;-) I get the feeling that a feature is being forced on all users because someone who pays for Nextcloud wants an edge case covered. Similar to how some marketing guy at GitHub thought it was more important to highlight the sign-up link instead of the log-in link. Because apparently people want to open a new account every day, but rarely log in with it again afterwards ;-) I also think conflict management should take place during saving and not afterwards when a file is reopened. Also, in 99% of cases, when I click save, I want those changes to be applied, and not, have to decide, in some cases a few weeks later, whether I want to undo the changes I made. I also often use the text app to quickly open a temporary note on another device, and in that case it's very annoying to have to confirm a promt first. Not to mention that the promt is confusing, and it has happened to me several times that I have accidentally undone my changes. |
I have reproduced this 'bug'. It is not a 'feature', it breaks 'file sharing' and replaces it with some sort of 'versioned publishing'. |
I'm also struggling with this.
Now, when opening the public-facing share link in a browser, I expect to see those changes which were synced. Instead, unexpectedly, it shows the old version of my file. I'm really not sure how this could be properly fixed, as the conflict/resolution behavior is really helpful in the right scenario. Providing an option to disable the behavior wouldn't be a bad place to start for now, though, if that's possible. |
I'm struggling with the same issues as others have explained, e.g. #4078 (comment) A couple of things with the UX on the situation I'd like to point out: "The document has been changed outside of the editor. The changes cannot be applied."What is the meaning of this message? "Use current version | Use saved version"This section is much more obvious as it shows the differences between the files and the buttons are located in a way that it's intuitive enough that there's little confusion as to what the result would be. But I do agree that the wording is confusing. I'm not a native English speaker so I can't suggest something rock solid, but perhaps "Use old version" | "Use new version" would make it less confusing? General / Thoughts
There's a very similar, if not identical, issue in the Notes app git: nextcloud/notes#1083 |
29.0.3 without any office suite. When I create .txt file on synced dir, put Also, Is I reopen locally file with |
Steps:
What happens
BUT: There is actually no conflict, as the browser didn't do any change
What should have happen:
Detect that there was a change from outside and that the document in the cpollaborative editor was not changed in the meantime and just put the new document into the view.
The text was updated successfully, but these errors were encountered: