Created attachment 173818 [details] tableJumping_minimal.doc: clicking in table makes it jump every time. Starting with LO 6.3.3 (and still true in 7.3+), every click inside of the table in this minimized document causes the table to jump back and forth. The cursor is lost in the transition as well, so it isn't simply a matter of scrolling and getting back to work. On the next click, it jumps again - making it basically impossible to edit the table contents. [In 7.3 master, after roughly 10 clicks, it settles down.] This started in LO 6.3.3 with author Miklos Vajna on 2019-09-17 18:57:09 +0200 commit d5b50e74ee822e1c8402e3044e14799e47907ff8 tdf#105330 sw: fix lost cursor on undoing nested table insert https://cgit.freedesktop.org/libreoffice/core/commit/?id=d5b50e74ee822e1c8402e3044e14799e47907ff8 It might be worth noting that sometimes you can see the cursor sitting somewhere in the middle of the first, mostly-empty page - somewhere that it should be impossible for it to be. CC'd Miklos ------------------------------------------------- Further background related to bibisecting this: Starting in 7.0, LO would crash after 4 or 5 clicks, because of Armin's https://cgit.freedesktop.org/libreoffice/core/commit/?id=424312aa99307da9f0ee60ea6e3213b2b3dc26b4 Then in 7.0.2, Noel fixed the crashing with https://cgit.freedesktop.org/libreoffice/core/commit/?id=445cf499666f21c2d480ce1df9ce6004b9450b64 N.B. Somewhere in 7.0 (after the crashing started), it seems as if something has caused the jumping to settle down after a while. After about 10 clicks or so, it stops jumping around and editing can happen. This is seen immediately with Noel's 7.0.2 patch. That still holds true in 7.3+.
Oh, that's annoying. Reading the commit message of d5b50e74ee822e1c8402e3044e14799e47907ff8 now I recall that this was a revert: so the above problem was "fixed" between e4509eea8fc7c07ddff48edf0d4c015c2663d896 and d5b50e74ee822e1c8402e3044e14799e47907ff8, but only by causing side effects like bug 105330, i.e. I fear this never really worked.
Yes, that was my conclusion too, that your commit just exposed an existing problem.
No repro. Justin: can you re-check? Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: 2f2df626117380427d2e5e8417316f52823f1e6f CPU threads: 8; OS: Linux 5.17; UI render: default; VCL: kf5 (cairo+xcb) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 55b20c8781d7718fa992769df90282563694f7fe CPU threads: 2; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: fi-FI (fi_FI); UI: en-US Calc: threaded Jumbo
(In reply to Buovjaga from comment #3) > Justin: can you re-check? Yes, I reproduce immediately. Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: 2475a552255fc100f2054d18dd85d3b044481129 CPU threads: 4; OS: Linux 5.13; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
I can not reproduce any jumping in linux-bibisect repos, table keeps on the second and third pages: Version: 7.2.7.0.0+ / LibreOffice Community Build ID: 6fb5a87e31b7df01f4b212ab979ae57e8d4ab4fb CPU threads: 16; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: hu-HU (hu_HU.UTF-8); UI: en-US Calc: threaded Version: 7.4.3.0.0+ / LibreOffice Community Build ID: 403ff3d3ccba1498568e82e4840a12e53a188406 CPU threads: 16; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: hu-HU (hu_HU.UTF-8); UI: en-US Calc: threaded Version: 7.5.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: cfc8a8f5d841b3f84d207196153be67da7f60652 CPU threads: 16; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: hu-HU (hu_HU.UTF-8); UI: en-US Calc: threaded Can you give more detailed instructions / screenshots?
Confirmed working with bibisect 7.3 (.7 presumably), thanks to commit dadaf930d14283f96cc06741d2eec6d846e59f7f Author: Michael Stahl on Mon Jul 11 19:20:33 2022 +0200 sw: fix spurious layout invalidation from ~SwCallLink() Thanks Michael!