Description: Empty textbox after undo Steps to Reproduce: 1. Open attachment 167355 [details] 2. CTRL+A 3. CTRL+X 4. CTRL+Z Actual Results: First textbox on page 1 empty Expected Results: Probably not Reproducible: Always User Profile Reset: No Additional Info: Version: 7.1.0.0.alpha1+ (x64) Build ID: 312a33b7636334f6ce3b6d1702bc5d3e45215601 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
Found in 7.0 and in 6.2 not in Version: 6.0.6.0.0+ Build ID: c30963b8b4bbbe42a24b97aafa161eff9d7ccdd4 CPU threads: 4; OS: Windows 6.3; UI render: default; Locale: nl-NL (nl_NL); Calc: CL
Confirm with Version: 7.1.0.0.alpha1+ Build ID: 548d77d0c06f7088dd3eb408797aa1fc1d7eb277 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3 Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US Calc: threaded
This seems to have begun at the below commit. Adding Cc: to Michael Stahl ; Could you possibly take a look at this one? Thanks 96e32c66b32fd6131afd80030ede3dc56a8509cb is the first bad commit commit 96e32c66b32fd6131afd80030ede3dc56a8509cb Author: Jenkins Build User <tdf@pollux.tdf> Date: Wed Sep 19 21:16:52 2018 +0200 source 723728cd358693b8f4bc9d913541aa4479f2bd48 commit 723728cd358693b8f4bc9d913541aa4479f2bd48 [log] author Michael Stahl <Michael.Stahl@cib.de> Wed Aug 22 17:09:02 2018 +0200 committer Michael Stahl <Michael.Stahl@cib.de> Wed Sep 19 10:18:29 2018 +0200 tree 1ac75a662a46987301ea85d32957eb08f435ffd6 parent 41d8ca9686c7c184f586e99674b443c34bfd4f33 [diff] sw_redlinehide_2: SwUndoDelete
Bumping this one to highest/critical.. not specific for this bug.. but more as ' example' for the whole group of bugs point this specific commit.. Causing rendering hideous rendering issues A text-editor needs to be trusted.. And disappearing stuff on screen doesn't help. This might be seen as (unharmful) glitch at developer level (if you're aware what's happening) But think end-user will judge otherwise.. I expect few other issues (copy/paste image with caption frame not appears) also be related.. even though bibisect will point to different commit, only uncovering this again Feel free to adapt the priority if i'm to aggressive with it :P. Only based on my current mood after bibisecting a bug, to his specific commit
(In reply to Telesto from comment #4) > Bumping this one to highest/critical.. not specific for this bug.. but more > as ' example' for the whole group of bugs point this specific commit.. > > Causing rendering hideous rendering issues A text-editor needs to be > trusted.. And disappearing stuff on screen doesn't help. > This might be seen as (unharmful) glitch at developer level (if you're aware > what's happening) But think end-user will judge otherwise.. > > I expect few other issues (copy/paste image with caption frame not appears) > also be related.. even though bibisect will point to different commit, only > uncovering this again > > Feel free to adapt the priority if i'm to aggressive with it :P. Only based > on my current mood after bibisecting a bug, to his specific commit I think high/major is enough to reflect the whole group of bugs pointing to the specific commit.
can't reproduce this with current master. bibisect in linux-64-7.2 finds this commit appears to have fixed it: commit 3bc8f90e9693f710f12632f69b9348c1c833c906 Author: Michael Stahl <michael.stahl@allotropia.de> AuthorDate: Fri Mar 5 21:06:28 2021 +0100 Commit: Miklos Vajna <vmiklos@collabora.com> CommitDate: Mon Mar 8 12:21:42 2021 +0100 (related: tdf#133487) sw: fix ordering of virtual SdrObjects for textboxes Calling XShapes3::sort() on export of the testTdf130314 fails because of 2 consecutive textboxes; the function requires a textbox to immediately follow its shape in the list (i.e. textbox has OrdNum of shape + 1). This is because for shapes in header/footer, one virtual SdrVirtObj is created per page where the header/footer is shown, and the SwFlyDrawContact::GetOrdNumForNewRef() does not take textbox ordering into account. It's not clear if the assumption that the shape's SdrVirtObj is created before the textbox's always holds, but let's try this for now. Change-Id: I860896471211bf6c142ab825f298f4d4c0eec148 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112029 ... the same commit is claimed to have fixed tdf#140292 too... oh that one is basically a duplicate! *** This bug has been marked as a duplicate of bug 140292 ***