Description: Redo puts cursor inside comment box if track changes record being enabled and show changes OFF Steps to Reproduce: 1. Open attachment 173161 [details] 2. Place cursor after X 3. Press Backspace 2x 4. Press CTRL+Z (2x) 5. Press arrow left/right (cursor inside comment box) Actual Results: Cursor inside comment box in the consternation of show changes ON, Track changes Record ON Expected Results: Same as the cases with Show Changes OFF or Record disabled Reproducible: Always User Profile Reset: No Additional Info: Version: 7.5.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 86b2bfd34a4f07c54f03c8c8dfe48e0810834628 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL
Also in Version: 7.1.8.0.0+ (x64) / LibreOffice Community Build ID: a94b58277c7aeaa83ce14347cd0b8f7137969d03 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL not in Version: 7.0.7.0.0+ (x64) Build ID: 626ea4e62a3e5005fe9825923a1c0c5bdb61cc08 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL smells like an implementation error, caused by tracking deletion of comment boxes.
I confirm it with Version: 7.5.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 4c96abd81460977d413d4d28e891bbbac5769ede 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 Additional inforations As far as I can see it only depends on record changes on
Stephane, I need help here, I don't know how to handle the source sha.... It's first time I see with multiple sha codes. 57367cd45c86541891b0144732c0ae4c76026bcf is the first bad commit commit 57367cd45c86541891b0144732c0ae4c76026bcf Author: Jenkins Build User <tdf@pollux.tdf> Date: Wed Nov 18 09:12:35 2020 +0100 source 0971eda1b4824b01f4d3b1e1e36ff6eb3bf37317 source 0971eda1b4824b01f4d3b1e1e36ff6eb3bf37317 source c446adbcbd0fac9668de9cb3c48f3b57b95ba785 source 63d8041c60c5d7c63dd34f94a694871b7ea9e2ca source d9391396434a5ad93f6796248c255b5bb2f3cba7 source c70b00820ec46035e50c7922876c5423c2f5f936 source aa433278f4276142250378ede75ef8aa9f16d972 source f493abe7edd7dc44855bec4b3a17a2cc32a597fe instdir/program/librptuilo.so | Bin 1778624 -> 1778624 bytes instdir/program/libswlo.so | Bin 22355136 -> 22355136 bytes instdir/program/libvcllo.so | Bin 15824408 -> 15824280 bytes instdir/program/libxolo.so | Bin 6330784 -> 6330744 bytes instdir/program/setuprc | 2 +- instdir/program/versionrc | 2 +- 6 files changed, 2 insertions(+), 2 deletions(-)
(In reply to BogdanB from comment #3) Thanks for the bibisect! Apparently multiple commits where grouped when building the bibisect repro. I would pick the the following commit based on the the commit message: https://git.libreoffice.org/core/+/63d8041c60c5d7c63dd34f94a694871b7ea9e2ca%5E!
(In reply to Telesto from comment #4) > (In reply to BogdanB from comment #3) > Thanks for the bibisect! Apparently multiple commits where grouped when > building the bibisect repro. I would pick the the following commit based on > the the commit message: > > https://git.libreoffice.org/core/+/ > 63d8041c60c5d7c63dd34f94a694871b7ea9e2ca%5E! Your link begins ok, but ends wrong https://git.libreoffice.org/core/+/63d8041c60c5d7c63dd34f94a694871b7ea9e2ca%5E%21
Justin, can you please have a look?
The problem here is that after the undo, the cursor has moved out of the text body, and into the comment. Comment 3's bibisect result is not correct. The difference is that prior to my fix, you couldn't (easily) get the cursor behind the comment. So your first backspace was deleting the x, not the comment, and the second backspace did nothing. The original steps to reproduce are overly complicated. Only a single backspace is necessary - the backspace that deleted the comment (and therefore only one undo). Steps to reproduce: -place the cursor after the x -press backspace (which deletes the comment) -press Ctrl-Z (to undo - the comment returns and the cursor is now in the comment) Prior to my commit, use DEL instead of BACKSPACE to get the same result. The cursor change is coming because the comment display "area" is appearing and disappearing (but of course not going away when track changes is showing - in that case the comment stays, but is crossed out). The disappearing/reappearing comment area started in LO 6.3 (backported to 6.2.0) with commit 32902f66e7749b2d06d13f50416be5323a0c0ea9 Author: Michael Stahl on Fri Nov 30 17:54:41 2018 +0100 sw_redlinehide: make layout based Show/Hide mode the default Adding CC to: Michael Stahl
bisecting in LO 6.2 with experimental mode turned on points to the commit that hides the comment margin when the comment is deleted. commit 683fd2d5726d0511a94681e5438b3c080b81cbba Author: Michael Stahl on Wed Dec 5 15:24:55 2018 +0100 sw_redlinehide_4b: consider the comments in the margin I assume what is happening is that normally the comment margin shows up when the first comment is created, so it is assumed that the cursor should be placed inside the comment. (Indeed, if we add a second comment to the provided bug document, the cursor is not moved when following the steps to reproduce.)
(In reply to Justin L from comment #8) > I assume what is happening is that normally the comment margin shows up when > the first comment is created, so it is assumed that the cursor should be > placed inside the comment. Indeed, the same behaviour is seen when turning off View - Comments, and then turning them back on.
Calling this a regression is not really appropriate. It is a consequence...