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

New live preview/editing feature locks files forever #5532

Closed
schiessle opened this issue Mar 19, 2024 · 5 comments · Fixed by #5579
Closed

New live preview/editing feature locks files forever #5532

schiessle opened this issue Mar 19, 2024 · 5 comments · Fixed by #5579
Assignees
Labels
0. Needs triage bug Something isn't working high
Milestone

Comments

@schiessle
Copy link
Member

schiessle commented Mar 19, 2024

How to use GitHub

  • Please use the 👍 reaction to show that you are affected by the same issue.
  • Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
  • Subscribe to receive notifications on status change and new comments.

Steps to reproduce

  1. Share a markdown document to a chat room (I assume office documents have the same issue)
  2. the chatroom will open a embedded text editor and show the file
  3. look in the files app at the file listing and/or on the desktop if you use the sync client
  4. the file is locked
  5. even after all users who are in the chat are closing the chat windows -> file is still locked
  6. delete the chat message with the file -> file is still locked

Expected behaviour

I think we need to have a way to decide if someone really edits the embedded document. Maybe the document should be opened and displayed by default in a read-only mode and only if people click on "edit" the file gets locked. If the keyboard focus leaves the embedded editor, the lock should be removed and the chat view switches back to read-only.

Actual behaviour

Once a file is shared to a room and showed with the embedded text editor, it seems to be locked forever. Even when the chat message was deleted again

Talk app

tested on c.nc.com (Nc 29 beta3)

@schiessle schiessle added 0. Needs triage bug Something isn't working labels Mar 19, 2024
@nickvergessen
Copy link
Member

I think we need to have a way to decide if someone really edits the embedded document. Maybe the document should be opened and displayed by default in a read-only mode and only if people click on "edit" the file gets locked. If the keyboard focus leaves the embedded editor, the lock should be removed and the chat view switches back to read-only.

Exactly my feelings about the feature, but unfortunately there is no option for this atm.
Anyway this is nothing Talk can fix. Not sure if it should be moved to Text or the Vue lib. Will ping others for clarification

@nickvergessen nickvergessen transferred this issue from nextcloud/spreed Mar 19, 2024
@juliusknorr
Copy link
Member

In addition Joas mentioned that Christoph also had issues with text grabbing the focus.

Regarding locking this is nothing we can change short term, we have discussed approaches with only locking a file as soon as there are some actual edits, but this is a technically challenging implementation effort and not feasible.

@jancborchardt I would see making the text editor a read only by default with a button to start editing the only feasible option to have a reasonably good experience. We can work on individual issues then mid-term to at some point bring back editable by default interactive widgets, but this seems to be too heavy for now.

@AndyScherzinger
Copy link
Member

@jancborchardt I would see making the text editor a read only by default with a button to start editing the only feasible option to have a reasonably good experience. We can work on individual issues then mid-term to at some point bring back editable by default interactive widgets, but this seems to be too heavy for now.

@juliushaertl @jancborchardt can we please do exactly this and have this for the release of 29? There isn't just an issue with locking, there is also the focus steal issue - you simply can't chat before all interactive widgets for editable fields are loaded since they keep stealing the cursor - I tried to write a message to marketing and just couldn't for nearly a minute, since while typing in the chat field, the cursor kept jumping into widgets. Given in many cases you might have more than one of those widgets loading you can't really edit them at once anyways.

@schiessle
Copy link
Member Author

Please also keep in mind that the same issue most likely also exists for Office documents. Just want to highlight it once more because the ticket is now now in the "text" repository.

@AndyScherzinger
Copy link
Member

Good point, @juliushaertl can you "duplicate" the issue for richdocuments too please? Thanks in advance

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
0. Needs triage bug Something isn't working high
Projects
Archived in project
Archived in project
Development

Successfully merging a pull request may close this issue.

5 participants