Issue autosave does not refresh content of edited post if the post was changed remotely

Summary

While editing an issue post, the changed content is autosaved and never refreshed if edit page is closed without clicking Cancel button.

Steps to reproduce

  1. Open any issue.
  2. Click pen button to edit the post.
  3. Start typing, ie, add a space.
  4. Change your mind and close the tab, or leave the page in any other way. DO NOT click Cancel button.
  5. Log in to Gitlab from another browser (use incognito mode, or, in real life, go home, and log in from your home pc)
  6. Open the same issue, edit the same post and save changes
  7. Go back previous browser (ie, go back to work next day)
  8. Open the issue again.
  9. You see changed content you have entered in another browser (at home)
  10. Start editing the post
  11. You see the source as you have left it at point 4. without any warning, that you or anyone else changed the post meanwhile.

In our case the post contained a To-Do list which I was updating. The content could be changed both by me, or by any other team member, even just by clicking the

  • checkbox.

Example Project

Might be reproduced on any issue in any project, at least in Gitlab-CE from version 10.x to 11.0.2

What is the current bug behavior?

There is no indication that I am editing old content. If it wasn't me who changed the post, but for example one of my colleagues, I would overwrite the changes and learn about that only after he yelled that someone destroyed his work.

Also, there is no obvious way to clear the old, autosaved source.

The old content is saved to LocalStorage, without any timestamp or checksum of before-edit content, under the key following this scheme: autosave//namespace/project-name/issues/..., where ... depends on the issue.

Only way to clear the old contents from interface is clicking Cancel on the edit page. Which I have missed as on my crapy work monitor it does not look like a button, the contrast of gray lines is to low for my eyes.

What is the expected correct behavior?

At least I expect information, that the source was changed since have left the editor.

There is already a message This comment has changed since you started editing, please review the updated comment to ensure information is not lost. which is displayed if somebody changes the same post while I have editor opened, regardles of any changes I make (ie, I am editing a checklist, and somebody checkes a checkbox, I immediatelly see the message). The same, or similar message should be displayed if outdated autosave is loaded.

I should be given a choice to either keep editing my version or reload the post to edit current content. In perfect world I should be able to see diff between autosaved and current version.

Relevant logs and/or screenshots

Screencast of the issue

Output of checks

n/a

Results of GitLab environment info

Expand for output related to GitLab environment info 
System information
System:		Debian 7.11
Current User:	git
Using RVM:	no
Ruby Version:	2.4.4p296
Gem Version:	2.7.6
Bundler Version:1.16.2
Rake Version:	12.3.1
Redis Version:	3.2.11
Git Version:	2.17.1
Sidekiq Version:5.1.3
Go Version:	unknown


GitLab information
Version:	11.0.2
Revision:	d9540ee
Directory:	/opt/gitlab/embedded/service/gitlab-rails
DB Adapter:	postgresql
URL:		https://gitlab.in.veracomp.pl
HTTP Clone URL:	https://gitlab.in.veracomp.pl/some-group/some-project.git
SSH Clone URL:	git@gitlab.in.veracomp.pl:some-group/some-project.git
Using LDAP:	yes
Using Omniauth:	no


GitLab Shell
Version:	7.1.4
Repository storage paths:
  • default: /var/opt/gitlab/git-data/repositories Hooks: /opt/gitlab/embedded/service/gitlab-shell/hooks Git: /opt/gitlab/embedded/bin/git

Results of GitLab application Check

Expand for output related to the GitLab application check 
Checking GitLab Shell ...

GitLab Shell version >= 7.1.4 ? ... OK (7.1.4)
Repo base directory exists?
default... yes
Repo storage directories are symlinks?
default... no
Repo paths owned by git:root, or git:git?
default... yes
Repo paths access is drwxrws---?
default... yes
hooks directories in repos are links: ...
3/1 ... ok
3/2 ... ok
3/5 ... ok
3/6 ... ok
3/9 ... ok
3/10 ... ok
3/11 ... ok
3/12 ... ok
9/13 ... ok
3/14 ... ok
3/16 ... ok
4/19 ... ok
3/20 ... ok
3/21 ... ok
9/22 ... ok
9/23 ... ok
3/24 ... ok
3/25 ... ok
3/29 ... ok
3/32 ... ok
3/34 ... ok
3/35 ... ok
3/36 ... ok
3/37 ... ok
3/38 ... repository is empty
3/41 ... ok
3/42 ... ok
Running /opt/gitlab/embedded/service/gitlab-shell/bin/check
Check GitLab API access: OK
Redis available via internal API: OK


Access to /var/opt/gitlab/.ssh/authorized_keys: OK
gitlab-shell self-check successful


Checking GitLab Shell ... Finished


Checking Sidekiq ...


Running? ... yes
Number of Sidekiq processes ... 1


Checking Sidekiq ... Finished


Reply by email is disabled in config/gitlab.yml
Checking LDAP ...


Server: ldapmain
LDAP authentication... Success
LDAP users with access to your GitLab server (only showing the first 100 results)
[ entires removed ]
Checking LDAP ... Finished


Checking GitLab ...


Git configured correctly? ... yes
Database config exists? ... yes
All migrations up? ... yes
Database contains orphaned GroupMembers? ... no
GitLab config exists? ... yes
GitLab config up to date? ... yes
Log directory writable? ... yes
Tmp directory writable? ... yes
Uploads directory exists? ... yes
Uploads directory has correct permissions? ... yes
Uploads directory tmp has correct permissions? ... yes
Init script exists? ... skipped (omnibus-gitlab has no init script)
Init script up-to-date? ... skipped (omnibus-gitlab has no init script)
Projects have namespace: ...
3/1 ... yes
3/2 ... yes
3/5 ... yes
3/6 ... yes
3/9 ... yes
3/10 ... yes
3/11 ... yes
3/12 ... yes
9/13 ... yes
3/14 ... yes
3/16 ... yes
4/19 ... yes
3/20 ... yes
3/21 ... yes
9/22 ... yes
9/23 ... yes
3/24 ... yes
3/25 ... yes
3/29 ... yes
3/32 ... yes
3/34 ... yes
3/35 ... yes
3/36 ... yes
3/37 ... yes
3/38 ... yes
3/41 ... yes
3/42 ... yes
Redis version >= 2.8.0? ... yes
Ruby version >= 2.3.5 ? ... yes (2.4.4)
Git version >= 2.9.5 ? ... yes (2.17.1)
Git user has default SSH configuration? ... yes
Active users: ... 10


Checking GitLab ... Finished

Possible fixes

(If you can, link to the line of code that might be responsible for the problem)

Edited by 🤖 GitLab Bot 🤖