Bug 65935 - Confusing "Readonly content cannot be changed" dialog for range based comments
Summary: Confusing "Readonly content cannot be changed" dialog for range based comments
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.1.0.0.beta2
Hardware: x86-64 (AMD64) All
: high minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks:
 
Reported: 2013-06-19 14:58 UTC by Jacek D.
Modified: 2015-12-15 11:03 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jacek D. 2013-06-19 14:58:45 UTC
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.
Comment 1 Emir Sarı 2013-06-19 15:24:48 UTC
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.
Comment 2 Jacek D. 2013-06-21 15:53:37 UTC
The same bug still exists in version: 4.1.0.1
Build ID: 1b3956717a60d6ac35b133d7b0a0f5eb55e9155
Comment 3 Emir Sarı 2013-06-21 15:55:23 UTC
©Jacek, just FYI, Version bug field should represent the first version bug has been seen, not the current reproducible version.
Comment 4 Jacek D. 2013-06-22 08:01:57 UTC
(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.
Comment 5 Kevin Suo 2013-06-27 14:34:47 UTC
I tried to reproduce from Jacek D.'s description, in Libreoffice 4.0.4.2.
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.
Comment 6 Michael Stahl (allotropia) 2013-07-05 15:36:49 UTC
this issue sounds much scarier than it actually is.

this message box was originally introduced in commits aa799f64723933bbb46544f835a970cfcbb90384
and 3ef488717f5925df2254bcc39bbbbe7b37fa9a0a
(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.
Comment 7 Miklos Vajna 2013-07-05 16:03:51 UTC
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?
Comment 8 Etienne Hirt 2013-10-23 20:18:33 UTC
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 4.1.1.2 the behaviour is correct.
Is this problem covered by this bug?
Comment 9 Miklos Vajna 2013-10-24 08:05:42 UTC
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".
Comment 10 Cédric Bosdonnat 2014-01-20 08:57:26 UTC
Restricted my LibreOffice hacking area
Comment 11 Björn Michaelsen 2014-10-16 14:59:14 UTC
(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".
Comment 12 Joel Madero 2015-01-05 17:16:43 UTC
Adding bibisected to whiteboard as bisected keyword is a subset of bibisected whiteboard.

Thanks!
Comment 13 Gordo 2015-05-03 20:18:42 UTC
Could not reproduce.

Version: 4.4.3.2
Build ID: 88805f81e9fe61362df02b9941de8e38a9b5fd16

4.1.6.2 reproducible
4.2.8.2 reproducible
4.3.6.2 not reproducible

Changed to RESOLVED WORKSFORME.
Comment 14 Robinson Tryon (qubit) 2015-12-15 11:03:32 UTC
Migrating Whiteboard tags to Keywords: (bibisected)
[NinjaEdit]