The character immediately preceding the start of a ranged (multi-character enclosing) comment cannot be deleted or replaced, and no character can be inserted immediately before a ranged comment. Example text: X[abcd]other Where "[abcd]" represents a ranged comment (highlighted in yellow). Attempts to delete "X" are silently ignored. Attempts to add text immediately before "[abcd]" produce a dialog with the complaint that "Readonly content cannot be changed. No modifications will be accepted". Observed in 4.1.0.0.alpha0+ (Build ID: bf5cf1a30bad7d831a501e5bf037ed83df8b200)
can you please attach a document that displays this behavior? Also provide step by step instructions on how to reproduce. Going to mark as NEEDINFO, once you provide these two things please change back to UNCONFIRMED and we'll take a look at it
Created attachment 71152 [details] Demonstrates ranged comment issue How to reproduce: 1. Open LibreOffice Writer (devbuild of 4.1, see also original bug report) 2. Type a sequence of characters (example: "Test", keep it to one line for simplicity) 3. Highlight all text (shortcut Ctrl-a) 4. From "Insert" menu select "Comment" (shortcut Ctrl-Alt-C) 5. Type at least one character into the margin comment 6. Click back into the main document's text 7. Press [Home] key to move cursor to very front of document (before comment) 8. Press a character (letter, number) of your choice. Expected behavior: Chosen character is inserted (outside/before comment range) Observed behavior: Dialog appears, stating "Readonly content cannot be changed. No modifications will be accepted". NOTE: Dialog is labeled "LibreOffice 4.1" as this is a devbuild (see build ID in original report). NOTE: It appears that any ranged (1+ length) comment exhibits this behavior, no matter where it is located (start of a line/paragraph, middle, whatever). The "old" style comments (single position/marker) are fine.
Confirmed, marking: New (Confirmed) Whiteboard (regression) Normal (can prevent high quality/professional work) Highest (regression + common feature (comments) + incorrect error message) Thanks for reporting and keeping this up to date. Version 4.1.0.0.alpha0+ (Build ID: dfd474710f959dcf78038deb990c3618b467ec6)
@K Udo Scheurmann: you're handling this bug? It's assigned to you so I just want to be sure
I will have a look (as would love to contribute!) but my experience with the code base is virtually nil, which is to say I only ever submitted a typo fix that I happened across while looking for something else that I never found.
I'm going to go ahead and mark this as default then for assigned to so that if another dev sees it they'll take it over. Since it's a regression it'll get higher priority and hopefully be fixed by release.
Hard to see how this is a regression, as far as I see this is only triggered by the new commented text range feature. Anyway, I'm taking a look.
@Miklos Vajna: Whether this is a regression is debatable, but it is a misfeature involving the (new ranged) comment. In any case, thanks for looking at this! I have spent some hours digging through the code, but haven't managed to get my head around how it all hangs together. What I have come away with, however, is the sense that the marker at the front of the range is probably marked read-only, but this read-only state "bleeds" into the preceding character because some other part of the code (perhaps because of an error-by-one) mistakes the read-only state of the marker as applying to the preceding character. I may be completely off, but maybe this helps. At least I hope it does not send you off on a wild goose chase.
Miklos Vajna committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=fd0da52d371ca13d66be3b04d89f9d9cf73baddd fdo#57938 SwPaM::HasReadonlySel: commented text ranges are not read-only The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Fixed in master, marking as resolved. -4-0 review: https://gerrit.libreoffice.org/1629
Miklos Vajna committed a patch related to this issue. It has been pushed to "libreoffice-4-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=5a0dc1d1fdeac4b06b39ea616374d3f81b6be8a9&h=libreoffice-4-0 fdo#57938 SwPaM::HasReadonlySel: commented text ranges are not read-only It will be available in LibreOffice 4.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Test result: It is better now, but not fixed: A character located immediately before the ranged comment can be inserted (that's an improvement), but deleting a character immediately preceding the ranged comment still does not work (no matter if that character was present before the ranged comment was defined, or was inserted later). How to reproduce: Step 1-8 as in comment 2, then: 9. Press backspace Expected behavior: Typed character is removed again. Observed behavior: Character is not removed. Also: If the character typed in step 8 (see comment 2) was a newline/Enter the backspace in step 9 causes the cursor to skip backwards over the newline; if it was a "normal" character, the cursor does not move at all. In either case the character immediately before the ranged comment is not removable (not with [Delete] key, or any other means) so long as the ranged comment persists. Note: Inserting another character between the undeletable character and the start of the ranged comment will cause the newly inserted character, which is now the one immediately before the ranged comment, to become "stuck" (not deletable) instead. Reopening as original bug report mentioned inability to delete, even if Steps to Reproduce were not as explicit.
Miklos Vajna committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=50b6dc0099ff61050b82a2e37e70d643151e7ce7 fdo#57938 SwPaM::HasReadonlySel allow editing before commented text ranges The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Miklos Vajna committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=bf670bcd5e60eae95a6bd297391799f13e55db9d fdo#57938 testcase The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
The char deletion problem is now resolved on master, -4-0 review: https://gerrit.libreoffice.org/1673
Tested: Works as expected now.
Miklos Vajna committed a patch related to this issue. It has been pushed to "libreoffice-4-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=f39fa5aad48dc93bf24a328297635e5e46a65cff&h=libreoffice-4-0 fdo#57938 SwPaM::HasReadonlySel allow editing before commented text ranges It will be available in LibreOffice 4.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
it looks like bug 68404 looks some thing like this, could some one take a look pleass? Thank you in advance, Thomas