With track changes active with "record" on but "show" off, when I delete a character from the end of a word, then double click the word, then press ctrl F to open the "Find" dialogue what appears in the find box includes the character I deleted. This then means the word I click on will not be found. A specific example: 1) Start with a document containing the text "Dogs, and cats". 2) Enable "track changes" with "record" but not "show". 3) Remove the comma after Dogs. The document now appears to contain "Dogs and cats". 4) Double click the word "Dogs". 5) Press ^F to open the "Find" dialogue. 6) Press enter Result: The "Find" box contains "Dogs," and the word that was edited is not found. Expected result: The "Find" box should contain "Dogs" - since that is what is now on the screen - and the word that was edited should be found
Another example - suppose I change "cats" to "cots" - my screen shows "cots" - double click and press ^F and the Find dialogue opens with "coats". Not only does this not exist on the screen but it also doesn't exist in either the old or new version of the document. Is this the intended behaviour ? It doesn't seem to make sense - this issue came to me from a friend who has been a copy editor for 20+ years and it doesn't make sense to her either
Bibisected with linux-64-6.2 to ae2232366f00e08c1855667cfaf068269ac9af2f sw_redlinehide_2: view cursor movement, Word/Sentence functions I used the env var SW_REDLINEHIDE=1 to see the issue. I learned of it after these other results along the way: 32902f66e7749b2d06d13f50416be5323a0c0ea9 sw_redlinehide: make layout based Show/Hide mode the default ae3150b1e1863e854224c2e41c7e50991f945dad sw_redlinehide_2: replace SW_REDLINEHIDE with ExperimentalMode config
Find & replace dialog (Ctrl-H) does not show the unexpected behaviour btw.
fixed on master
Michael Stahl committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/1f540c49e68b28a360ee5c32d60ab1bed3837eec tdf#158277 sw_redlinehide: fix find bar string It will be available in 24.8.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.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/d41053defd59257a13916a096da40db152b4b41e tdf#158277 sw_redlinehide: fix find bar string It will be available in 24.2.1. 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.
Michael Stahl, thanks for fixing this. Duncan, thanks for reporting. Good in (just Dogs) Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 4d0f2d5ec9f7f988a1493916ae35bac1986c95a8 CPU threads: 16; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded Bad in (for comparison reason) (Dogs,) Version: 7.6.2.1 (X86_64) / LibreOffice Community Build ID: 56f7684011345957bbf33a7ee678afaf4d2ba333 CPU threads: 16; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded
Xisco Fauli committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/fa356a8bfc45e14f4ae9a7a0c80c269a32b241fe tdf#158277: sw: Add UItest It will be available in 24.8.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.