Bug 138297 - Outer frame and inner text frame mismatch after anchor change and broken even after undo (DOCX)
Summary: Outer frame and inner text frame mismatch after anchor change and broken even...
Status: RESOLVED INSUFFICIENTDATA
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.4.7.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisectRequest, regression
Depends on:
Blocks: DOCX-Textbox
  Show dependency treegraph
 
Reported: 2020-11-17 21:58 UTC by Telesto
Modified: 2023-05-06 12:51 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
How it looks in 7.0 and in current 7.2 after changing anchor and undo (220.58 KB, image/png)
2021-02-08 07:29 UTC, NISZ LibreOffice Team
Details
Minimal file for demonstration (14.91 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2021-05-06 11:20 UTC, Attila Bakos (NISZ)
Details
Wrap settings on opening is set to behind text (157.93 KB, image/jpeg)
2022-06-30 14:33 UTC, Attila Bakos (NISZ)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2020-11-17 21:58:20 UTC
Description:
Outer frame and inner text frame mismatch after anchor change and broken even after undo

Steps to Reproduce:
1. Open attachment 167355 [details] (see also bug 138282 and bug 138290) with 4.4.7.2
2. Select they (Hebrews 4:13a) frame on top of page 1
3. Change anchor to character -> Noticing something being off
4. Press CTRL+Z

Actual Results:
Frame and text box detaching after anchoring change. And undo makes it worse

Expected Results:
Should work


Reproducible: Always


User Profile Reset: No



Additional Info:
Found in
7.1

and in
Versie: 4.4.7.2 
Build ID: f3153a8b245191196a4b6b9abd1d0da16eead600
Locale: nl_NL
Comment 1 Telesto 2020-11-17 22:00:03 UTC
Everything OK with (there is brokenness but different)
Versie: 4.2.0.4 
Build ID: 05dceb5d363845f2cf968344d7adab8dcfb2ba71
Comment 2 Telesto 2020-11-17 22:04:05 UTC
@NISZ 
It concerns DOCX + textboxes and you're doing work in this area/ care about this. Source issue likely a Miklos commit, does feel like a duplicate. More if this type of issues in they 4.3 branch
Comment 3 zcrhonek 2020-11-20 11:42:26 UTC
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
Comment 4 NISZ LibreOffice Team 2020-11-24 11:39:16 UTC
This happens when the right click menus To Character is used not when it is set in the Position and Size dialog.

Also happens since 4.4, in 4.3 the shape was imported as a frame.

@Attila maybe one more for you...
Comment 5 NISZ LibreOffice Team 2021-02-08 07:29:59 UTC
Created attachment 169570 [details]
How it looks in 7.0 and in current 7.2 after changing anchor and undo

Undo is still broken in:

Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 3ed9bba283a6a67864c0928186e277240be0d9ba
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: en-US (hu_HU); UI: en-GB
Calc: CL
Comment 6 NISZ LibreOffice Team 2021-04-23 13:26:19 UTC
Still happens in

Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: db1cf111666847ce5ce93d18ae5ae8c29a4c44d6
CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win
Locale: hu-HU (hu_HU); UI: en-US
Calc: threaded
Comment 7 Attila Bakos (NISZ) 2021-05-06 11:20:29 UTC Comment hidden (obsolete)
Comment 8 Attila Bakos (NISZ) 2022-06-30 14:23:19 UTC
(In reply to Attila Bakos (NISZ) from comment #7)
> Created attachment 171689 [details]
> Minimal file for demonstration
> 
> And, I have reached this issue...
> 
> This file shows the real problem: there is no problem with the textbox or
> undo. (because there is no textbox at all :) The problem the following:
> 
> The shape is anchored to paragraph "blablabla". When I change the anchor to
> char, this happens: The program finds the new position for the anchor and
> the paragraph with the "Lorem", will be chosen because it is the closest for
> the shape. But, the position of the shape is a large amount of negative
> number because it has been anchored to the "blablabla" para which has been
> aligned to right, and the shape is on the left side of it. So the anchor
> position changes the shape offset not -> this cause the shifting to left.
> (And the wrap changing as well)
> To summarise up, this is rather wrap and layout problem.
> 
> Regression confirmed, this is not problem in 3.6 but it occurs in 4.4.

this is not belong to this bug, i think...
However, detaching no longer occurs in:
Version: 7.5.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 4a8a3b1930ac029471fa9264396bd7fc020cfbef
CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win
Locale: hu-HU (hu_HU); UI: en-US
Calc: CL
Recheck suggested. However the surround still changes to behind text at undoing.
Comment 9 Attila Bakos (NISZ) 2022-06-30 14:33:30 UTC
Created attachment 181036 [details]
Wrap settings on opening is set to behind text

Update: Wrap also good after undo, as my attachment shows that is set to behind text at import time. This might be a docx import issue only.
Comment 10 Attila Bakos (NISZ) 2022-07-08 09:18:26 UTC
(In reply to Attila Bakos (NISZ) from comment #9)
> Created attachment 181036 [details]
> Wrap settings on opening is set to behind text
> 
> Update: Wrap also good after undo, as my attachment shows that is set to
> behind text at import time. This might be a docx import issue only.

Nice... When i modified the filter, and this issue become fixed, the test of bug 137850 will be broken... In addition, the sample file seems to came from LO 6.4 without version info... And before v14 the import differs from the above in this case. So what to do? There are two file which have same content and one of them have to open with behind doc and other without.. How to decide? :D Any idea?

Details:
In word/document.docx:
...
<w:drawing>
    <wp:anchor behindDoc="1" distT="0" distB="27305" distL="114300" distR="131445" simplePos="0" locked="0" layoutInCell="1" allowOverlap="1" relativeHeight="4">
        <wp:simplePos x="0" y="0"/>
        <wp:positionH relativeFrom="column">
...
        <wp:effectExtent l="0" t="0" r="0" b="0"/>
        <wp:wrapSquare wrapText="bothSides"/>
        <wp:docPr id="2" name="Text Box 3"/>
...
the interested parts are: behindDoc=1 and WrapSquare wrapText=bothsides elements.
The first indicates that the content have to be placed behind the text, the other overrides this and says this have to be wrapped by both sides (Word only can handle on one of this at same time). Both file (the sample of this bug and the bug 137850) have this content, but that have to placed behind doc, and this one haven't... In addition changing in Word the type from behind to square keeps the behind doc true... so nice.. :D
@Telesto: should this be closed with notabug or what is your idea? Which ticked should work from the two one? Or is this fixed because the detaching does not occur? What is your opinion?
Comment 11 Attila Bakos (NISZ) 2022-07-08 09:21:59 UTC
sorry, i meant in the previous comment word/document.xml of course.
Comment 12 QA Administrators 2023-04-05 03:23:57 UTC Comment hidden (obsolete)
Comment 13 QA Administrators 2023-05-06 12:51:27 UTC
Dear Telesto,

Please read this message in its entirety before proceeding.

Your bug report is being closed as INSUFFICIENTDATA due to inactivity and
a lack of information which is needed in order to accurately
reproduce and confirm the problem. We encourage you to retest
your bug against the latest release. If the issue is still
present in the latest stable release, we need the following
information (please ignore any that you've already provided):

a) Provide details of your system including your operating
   system and the latest version of LibreOffice that you have
   confirmed the bug to be present

b) Provide easy to reproduce steps – the simpler the better

c) Provide any test case(s) which will help us confirm the problem

d) Provide screenshots of the problem if you think it might help

e) Read all comments and provide any requested information

Once all of this is done, please set the bug back to UNCONFIRMED
and we will attempt to reproduce the issue. Please do not:

a) respond via email 

b) update the version field in the bug or any of the other details
   on the top section of our bug tracker

Warm Regards,
QA Team

MassPing-NeedInfo-FollowUp