Description: Correcting with spell checker context menu places cursor at the left (previously left) Steps to Reproduce: 1. Open the attached file 2. Right click wrong spelled word Actual Results: Cursor at the left Expected Results: A) This is a change in logic B) Other spell checkers do right too Reproducible: Always User Profile Reset: No Additional Info: Version: 7.1.0.0.alpha1+ (x64) Build ID: ec1f4d3253963ac16d638734ac70dde033e82154 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: nl-NL Calc: CL
Created attachment 166983 [details] Example file
@Michael They recent change you made for replacing text has small side effect (else anchors got eating). Cursor is put left, instead of right. Not sure if there are practical side effects but it's change in logic and bit odd.
Bisected to: author Michael Stahl <Michael.Stahl@cib.de> 2020-08-19 18:55:27 +0200 committer Michael Stahl <michael.stahl@cib.de> 2020-08-20 13:47:08 +0200 commit ec579354af954867b829e7d08e4d752518c83728 (patch) tree e2fea1fd4729fedf648f129a0e927674b4235c7a parent 6274fbe13c8fa556916b5aed695c6921ef6ff84f (diff) tdf#135721 sw: fix spell check context menu deleting flys Kind of similar to e1629c210ad78310e3d48c0756723134a27b89df but the problem is at a higher level: SwTextShell::Execute() with SID_SPELLCHECK_APPLY_SUGGESTION should not DelLeft() + Insert() but just Replace(). (regression from 28b77c89dfcafae82cf2a6d85731b643ff9290e5) https://cgit.freedesktop.org/libreoffice/core/commit/?id=ec579354af954867b829e7d08e4d752518c83728
uh... is that a bug? not sure if users care?
(In reply to Michael Stahl (CIB) from comment #4) > uh... is that a bug? not sure if users care? It's a difference. Not sure if this would cause practical issue with macro/undo/redo or whatever. And of course habit :-). I never really noticed it, but after the change I found something being off. I still not really know what's makes it different, but somehow it's strange. And the right click replace mostly placed cursor right (in other programs). So there might be a reason. Anyhow I call it change in logic. But if you want to do a 'social experiment' to check if anybody notices: also fine :P
@Heiko Any opinion on this? I'm realizing this being a kind of UX topic. Say I'm typing and a red line appears.. I read click it and select the corrected version.. I tend to press space and go on where I left.. but with cursor at the wrong position this doesn't work anymore.. However I might be me.. so asking the actual usability expert :P. Not seen anyone complain yet (except me)
Let's call it a minor discrepancy. The cursor is also left in case of RTL text flow. Continuing at the end of the word is the usual progress of editing, so yes. Tested with 6.4.
*** Bug 141693 has been marked as a duplicate of this bug. ***
*** Bug 148219 has been marked as a duplicate of this bug. ***
*** Bug 148813 has been marked as a duplicate of this bug. ***
Still present in Version: 7.3.4.1 (x64) / LibreOffice Community Build ID: 13668373362b52f6e3ebcaaecb031bd59a3ac66b CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: CL Related to bug 102044
Still present in Version: 7.4.0.3 / LibreOffice Community Build ID: 40(Build:3) CPU threads: 8; OS: Linux 5.19; UI render: default; VCL: gtk3 Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR 7.4.0-2 Calc: threaded For me it is a real issue
*** Bug 149854 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of bug 109272 ***
Expected result is to jump to the right. Reason for jump to the right: Often the suggested word is mostly right but needs a small change - like an s to give the plural. But the cursor is stranded at the beginning of the word.
This is not an enhancement! What is needed is a return to the correct behaviour found in previous versions - and on every spell checker I ever came across.
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/4f93995f2262cde0b16bacc83f4ba3c6161ada7f tdf#137972: when correcting PaMs, move them to the end It will be available in 7.6.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.
Much better on the right. Verified with Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 900c3a2a854436fdbacd488ef1da12ea99fbceb0 CPU threads: 16; OS: Linux 5.19; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded Bad in Version: 7.5.3.2 (X86_64) / LibreOffice Community Build ID: 9f56dff12ba03b9acd7730a5a481eea045e468f3 CPU threads: 16; OS: Linux 5.19; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded