Skip to content
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

Open
tzugen opened this issue Apr 25, 2023 · 18 comments

Comments

@tzugen
Copy link

tzugen commented Apr 25, 2023

Steps:

  • Create a new file, Test.md on a folder synced with Nextcloud client
  • Add some text
  • Open your browser and go to the file. It should display fine.
  • Add new text using your desktop editor
  • Switch back to the browser.

What happens

  • The browser will show a warning "The file has been edited outside" and will show two contents side by side.
    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.

@tzugen tzugen added the bug Something isn't working label Apr 25, 2023
@blizzz blizzz added enhancement New feature or request and removed bug Something isn't working labels Jun 13, 2023
@blizzz
Copy link
Member

blizzz commented Jun 13, 2023

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.

@blizzz
Copy link
Member

blizzz commented Jun 13, 2023

cc @nextcloud/designers for UX impact

@tzugen
Copy link
Author

tzugen commented Jun 14, 2023

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.

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.

@tzugen
Copy link
Author

tzugen commented Jun 14, 2023

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...

@blizzz
Copy link
Member

blizzz commented Jun 14, 2023

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.

@hugodu69
Copy link

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

@tzugen
Copy link
Author

tzugen commented Jun 14, 2023

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.

Yes, thats right. I guess that it won't be possible to implement this if a change is coming from external.

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

Thanks for putting it in different words, not sure if I explained it so good before..

@tzugen
Copy link
Author

tzugen commented Jun 14, 2023

https://github.com/nextcloud/text/blob/c967d0127151da5a64b770778c097a52e8b3c69a/lib/Service/ApiService.php#LL245C1-L252C5
On a cursory look this seems to be part of the problem. If I understand it right, the client will call Sync regularly, even if nothing changed in the browser (fine), but then the sync will trigger an unconditional call to autoSave, which will fail, because there is a newer file outside. But this call to autosave is not needed if no changes were done.

@blizzz
Copy link
Member

blizzz commented Jun 16, 2023

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.

@hugodu69
Copy link

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 ;)

@XueSheng-GIT
Copy link

I would argue that this behaviour is still a bug. Uploading a text file (webif or webdav) is no issue. Text file is displayed correctly in Nextcloud (without any changes to the file).
e.g.

Line 1
Line 2
Line 3

Changing that file ouside of text (e.g. adding a Line 4, leads to following message in text:
grafik
Whereas the 'latest version' is actually the outdated version and the saved version is the latest version. Confusing!

Nevertheless, if choosing 'saved version', the formatting of the file breaks!

Line 1 Line 2 Line 3 Line 4

This can't be the desired design/behaviour. Please reconsider marking this as a bug! Thanks!

@meonkeys
Copy link
Contributor

meonkeys commented Jul 25, 2023

changes were done outside of the editor, and you see the document as it was loaded

Oh woah, but why didn't it load the most recent server-side version first? I'm confused what "current" means in this context.

Whereas the 'latest version' is actually the outdated version and the saved version is the latest version. Confusing!

+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

@obrb
Copy link

obrb commented Jul 25, 2023

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.

@s4069b
Copy link

s4069b commented Oct 10, 2023

I have reproduced this 'bug'. It is not a 'feature', it breaks 'file sharing' and replaces it with some sort of 'versioned publishing'.

@BraidenPsiuk
Copy link

I'm also struggling with this.
Here's my scenario, which I think other people (at least those who edit text files locally on their computer) are experiencing:

  • I am editing a .md file using a markdown editor on my local computer.
  • This file is synced via the desktop client.
  • This file is also publicly accessible via a share link.
  • When I make changes and save the file using the editor on my local computer, these changes get synced without issue.
    (I can verify the changes were properly synced by viewing the file via WebDAV. Doing so, the file shows my new edits, as expected. There are no version conflicts reported by the desktop client, also as expected.)

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.
In order to resolve this, I must open the file using Text via the website or mobile client, and select the right-most option to keep/apply my changes.
This makes some sense for the users who only use the browser and only make edits there, but for the rest of us who use local editors and sync our changes, it feels like very unintuitive or even broken behavior- to be forced to resolve a conflict that doesn't exist in the first place. I really don't want to disable Text altogether- that's a really unfortunate workaround, because it's a fantastic app.

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.

@ristein
Copy link

ristein commented Mar 21, 2024

image
everytime I access a text file in browser or android-app that has been saved on pc and synced I get this. Super annoying. How to explain this to my less technical users?
How can this not be a bug?
Should users read through the entire file to eventually find the changes, then remember which one is the newer file and finally click on the button on the right every time (unnecessarily since there is no conflict) and think "this is not a bug would be an enhancement to just work as expected ??

@matrixes
Copy link

matrixes commented Apr 17, 2024

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?
I can see a point in "The document has been changed outside of the editor, you need to decide which version you want to keep using the buttons below.".
But the part about "The changes cannot be applied.";
Why can't they be applied, I didn't change the text in the file I'm looking at. What can I do about it? Is there an issue with the editor that I should contact support about? (I don't necessarily want an answer to these questions, but I'd like to express what a user may think when being met by the messages coming from Text/Notes)

"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

  • If the file is untouched in the web UI (that's where this message shows up), and there are changes coming in from elsewhere, wouldn't it be enough to use e.g. a toast (like the one that today says "The document has been changed outside of the editor...") to inform the user that the text being displayed is the new version (and have the editor reflect that).
  • Once there's an actual conflict (e.g. both the file in the web UI has changed and changes coming in from elsewhere have happened), then the user gets to choose which file to keep?

There's a very similar, if not identical, issue in the Notes app git: nextcloud/notes#1083

@bigretromike
Copy link

29.0.3 without any office suite.
Still there is issue.

When I create .txt file on synced dir, put 1 inside, open that in webui and close, then I put in 2 via local notepad, wait for sync in desktop app or force the update, and reopen file in webui i still have 1 for longer time until it show me which version I want to pick the one with 1 or 2.

Also, Is I reopen locally file with 2 and just hit save, now when opening it via webui it ask me if I want 2 version or 2 version (current vs saved).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: 📄 To do (~10 entries)
Status: 🏗️ At engineering
Development

No branches or pull requests