Description: When a line ends with a period, and the final word before that period is commented, clicking to the right behind the end of the line (in the white space behind the final period) places the cursor *before* that period, not behind. Steps to Reproduce: 1. Open an empty Writer document. 2. Enter a sentence ending in a period, like: "This is a sentence." 3. Add a comment to the word "sentence". 4. Click in the white space to the right of the sentence. Actual Results: The cursor is placed between the word "sentence" and the period. Expected Results: The cursor is placed at the end of the line, behind the final period. Reproducible: Always User Profile Reset: Yes Additional Info:
I confirm this with Version: 6.2.0.0.alpha0+ (x64) Build ID: 48cfa0b00b22f11ade53aec79b2fdddad253e1bd CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-10-03_02:01:42 Locale: en-US (de_DE); Calc: CL
Reproduced back to Version 4.1.0.0.alpha0+ (Build ID: efca6f15609322f62a35619619a6d5fe5c9bd5a) but not in LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4
(In reply to Xisco Faulí from comment #2) > but not in > > LibreOffice 3.3.0 In 3.6.0.4 the comment is anchored to the starting point, not to the full word, this changed with 4.0.0.3, and the bug was also introduced in that version.
Still exists in version 6.3.0.0.alpha0+ (x64) Build ID: 0f25a3c36f27fd51453b9a9115f236b83c143684 CPU threads: 8; OS: Windows 10.0; UI render: GL; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-11-27_20:06:55 Locale: zh-TW (zh_TW); UI-Language: en-US Calc: threaded
cleanly bibisects to July 20-22, 2012 between bad commit 51065497ea83e90764860784dc6e193faaf0d673 and good commit 06f20d73da21342046a480a6b22af69901351328 but I didn't immediately see a likely culprit.
commit 2fe8ce572222e90327cfeed6b7da07a2c57bdbbb Author: Miklos Vajna Date: Fri Jul 20 14:41:23 2012 +0200 SwXTextField::attachToRange: don't generate new fieldmark id on each import NOTE: comment 3's note about the word being selected/highlighted by the comment is the same commit.
Created attachment 148844 [details] comment.odt: cursor not placed at end of the line - doesn't depend on selection, but just on the anchor position. When determining the width of the line, the comment anchor is considered to be two spaces wide. sal_uInt16 SwViewOption::GetPostItsWidth( const OutputDevice *pOut ) { return sal_uInt16(pOut->GetTextWidth(" ")); } When the anchor is near the end of the line, this fake space can be larger than the fullstop width, and so it thinks that it has found the correct location for the cursor. This hack fixes the bug... itrcrsr.cxx SwTextCursor::GetCursorOfst() if ( pPor->IsPostItsPortion() ) + { nWidth30 = 30 + pPor->GetViewWidth( GetInfo() ) / 2; + if ( nX && nWidth30 > nX ) + nWidth30 = nX-1; + } This "if it is a comment portion" section was added by https://cgit.freedesktop.org/libreoffice/core/commit/?id=dca044e9572144c1ba9ce423b10f7a5456837cda
Created attachment 167239 [details] comment.odt: tweaked to test the thinest character (|), and multi-comments. Miklos cautiously handled a similar issue in https://cgit.freedesktop.org/libreoffice/core/commit/?id=27c46ecf34b32bae1806d3fc0e1684179301feb8 for comments after flies. I guess in theory it could be extended for any portion with width zero. Handling a comment (or other zero width portions) at the very end of the line can be accomplished with: if (nWidth30 >= nX && (!pPor->IsFlyCntPortion() || !pPor->GetNextPortion()->IsPostItsPortion())) - return false; + return nWidth30 == nX && !pPor->GetNextPortion()->Width(); But who knows what all portions can have zero width, and that could have a LOT of unintended consequences. Also, this routine is called every time the cursor quivers - so tight coding is very important. Proposed fix: https://gerrit.libreoffice.org/c/core/+/105746 tdf120290 sw: move cursor behind comment at line end https://gerrit.libreoffice.org/c/core/+/105747 tdf#120290 sw: comment no longer needs any width
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/63d8041c60c5d7c63dd34f94a694871b7ea9e2ca tdf120290 sw: move cursor behind comment at line end It will be available in 7.1.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/3c4b09a250605c9d73e48df83a6ee36a8bc2fb8b tdf#120290 sw: comment no longer needs any width It will be available in 7.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I'm happy to not have this fixed until 7.2. That way if the first patch - which is the more dangerous - causes problems in 7.1, it is easier to revert the whole thing.
*** Bug 136872 has been marked as a duplicate of this bug. ***
*** Bug 132192 has been marked as a duplicate of this bug. ***
VERIFIED FIXED with Version: 7.2.0.0.alpha0+ (x64) Build ID: 9f9798f07f0b56ae474f31ded671cc8da598d244 CPU threads: 4; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: threaded Justin, thanks for fixing that issue!
*** Bug 136879 has been marked as a duplicate of this bug. ***