online
online copied to clipboard
Locking Documents
This resolves #9185.
The issue relates to loading asynchronously. This ahead-of-time loading is done before the client opens the WebSocket. This meant that the locking function didn't have the necessary details to decide whether locking was needed or not, and so it was skipped. The issue wouldn't happen if by the time we downloaded the document the WebSocket was created. As such, this is a time-sensitive bug. However, reports indicate that it's not uncommon that we weren't taking the lock.
The issue is resolved with this PR and now we take the lock when the first editor joins (and as before, we unlock when the last editor leaves). An improved unit-test asserts this behavior.
- wsd: all view-only extensions accept comments
- wsd: minor refactor around on-demand CFI
- wsd: always set view-file-extension flag
- wsd: reliable locking with async loading