I open a new document.
I type anything. Then I select the text and add a comment to it.
Then I hide and show comment bar by using a new feature.
Then I insert a table into a document (I use an icon to do this).
I select a few cells, right click and select Table.
I go to background tab, choose 'as graphics', then I click OK.
As the result the documents becomes read-only.
I can confirm this using the latest master on 10.7.5.
Since this is a high-priority bug, I am setting the bug info accordingly.
In my case, there was no need to add a table, after inserting comment and toggling the new comments button document became read-only immediately.
Note: It only seems to occur when attaching comments to a selection.
The same bug still exists in version: 220.127.116.11
Build ID: 1b3956717a60d6ac35b133d7b0a0f5eb55e9155
©Jacek, just FYI, Version bug field should represent the first version bug has been seen, not the current reproducible version.
(In reply to comment #3)
> ©Jacek, just FYI, Version bug field should represent the first version bug
> has been seen, not the current reproducible version.
Thank you, I will comply to your suggestion from now on.
I tried to reproduce from Jacek D.'s description, in Libreoffice 18.104.22.168.
and the behaviour happened during my operation, not after I inserted a table, but before it.
I have ever encounter the read-only issue several times before, but I am not sure how to reproduce it.
Close and re-open will be editable again.
this issue sounds much scarier than it actually is.
this message box was originally introduced in commits aa799f64723933bbb46544f835a970cfcbb90384
(initially for enhanced fields, but apparently range based
comments also have a dummy character) so that
the dummy characters that mark the start/end of particular
content cannot be deleted by the user.
for 4.1 this commit e047a967b0db8c61dc977b52f3876fc4e385ad77
added a new "Hide Comments" button on the ruler.
what happens if you use that button is that the cursor is put in the
position at the end of the range comment, directly on the
end dummy character, so the editing toolbar is disabled,
and entering keys results in the dialog box.
simply moving the cursor to the left or right enables editing again.
what i wonder though is why it's not sufficient to just adapt
lcl_DoWithBreaks in docedt.cxx to handle enhanced fields
and range based comments in addition to metadata fields,
which ought to prevent any disasters without annoying dialogs.
I think the behavior you hit is the one I implemented in bd505fdb9f669f365ff39b0ef46f0742c638e333 for bug 59573. As long as we have no way to prevent the cursor be positioned between the fieldmark end and the comment anchor, that position should be read-only.
Maybe e047a967b0db8c61dc977b52f3876fc4e385ad77 should be improved not to alter the position of the cursor?
When opening a .doc document that was commented in Word2000 (range comments) then the last letter of the commented range is hidden.
In case the comment was added in Libreoffice 22.214.171.124 the behaviour is correct.
Is this problem covered by this bug?
If you mean the last character of the commented text range is missing, then no, that would be a separate bug, please file it separately. This bug is about "you can place the cursor between the comment end and the comment anchor, which is read-only".
Restricted my LibreOffice hacking area
(This is an automated message.)
It seems that the commit that caused this regression was identified. (Or at least a commit is suspected as the offending one.)
Thus setting keyword "bisected".
Adding bibisected to whiteboard as bisected keyword is a subset of bibisected whiteboard.
Could not reproduce.
Build ID: 88805f81e9fe61362df02b9941de8e38a9b5fd16
126.96.36.199 not reproducible
Changed to RESOLVED WORKSFORME.
Migrating Whiteboard tags to Keywords: (bibisected)