Bug 146443 - Text Box or shape that anchors to an empty paragraph moves it's position to next paragraph when type Enter key at original paragraph
Summary: Text Box or shape that anchors to an empty paragraph moves it's position to n...
Status: RESOLVED NOTABUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.2.0.4 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Anchor-and-Text-Wrap Textbox Shapes
  Show dependency treegraph
 
Reported: 2021-12-28 04:51 UTC by Heesu Ban
Modified: 2022-01-11 14:37 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Heesu Ban 2021-12-28 04:51:36 UTC
Description:
In LibreOffice writer Version 7.2.4.1,
Text Frame that anchored to a paragraph moves it's position to next paragraph when typing Enter key at original paragraph.

Steps to Reproduce:
1. Create a Writer Document
2. Insert > Text Box,  Draw Text Box at the same line of first paragraph.
3. set mouse cursor to first paragraph.
4. press Enter key several times.


Actual Results:
New paragraph made by pressing Enter key, 
and Text Box moves down to below paragraph as much as pressing Enter key.

Expected Results:
Text Box should be sustained at first paragraph.


Reproducible: Always


User Profile Reset: No



Additional Info:
I tried to reproduce this symptom with several LibreOffice versions newly installed.
Version 6.4.7.2,  Not reproduced.
Version 7.0.6.2,  Not reproduced.
Version 7.1.8,    Not reproduced.
Version 7.2.4,    reproducible.
Version 7.3.0.1,  reproducible.
Comment 1 Mike Kaganski 2021-12-28 05:59:33 UTC
Most probably that's the fix to tdf#120469.
Comment 2 Dieter 2021-12-28 07:20:51 UTC
I confirm it with

Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 9c95415de877af1430ab5b7123e11dedd0ea622c
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


But not with

Version: 7.0.6.2 (x64)
Build ID: 144abb84a525d8e30c9dbbefa69cbbf2d8d4ae3b
CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: de-DE
Calc: CL

Additional informations
- If you change first paragraph to a different style than default, problem is more visible
- Same with shapes (=> I changed bug summary)
- Similar with images (but I can reproduce it  also with 7.0.6.2 and so I will file a new report
Comment 3 Dieter 2021-12-28 07:27:22 UTC
(In reply to Mike Kaganski from comment #1)
> Most probably that's the fix to tdf#120469.

Dipanshu, do you think, it is related to your fix of bug 120469? Cpuld you please have a look at it? Thank you.
cc: dipanshu@iitk.ac.in
Comment 4 Mike Kaganski 2021-12-28 07:34:24 UTC
(In reply to Dieter from comment #3)

But that's the essence of that change? The request was to *move* objects; and now this one wants the opposite.
Comment 5 Aron Budea 2021-12-28 07:55:57 UTC
Yes, that change was intentional, thus the behavior isn't a bug.
Comment 6 Heesu Ban 2021-12-28 08:00:24 UTC
If this is intended behavior at 7.2 and onward, personally I'm ok.

but there may be users, macros, UNO API program that was used to use the version earlier than 7.2.0, will face this change with later than 7.2.0.
I'm thinking how to handle to this with UNO API, but It seems not easy. 

Thanks for your attention anyway.
Comment 7 Dieter 2021-12-28 08:13:40 UTC
(In reply to Aron Budea from comment #5)
> Yes, that change was intentional, thus the behavior isn't a bug.

I disagree, intention of bug 120469 was that object moves down, if paragraph moves down. I agree with that. But problem here is that - as far as I can see - paragraph doesn't move down. You can easily see that, if you assign a style to the first paragraph.

Problem is only related to empty paragraphs. In a paragraph with text the problem doesn't appear, if you press enter at the end of the paragraph.

So I change status back to NEW and hopefully my explanations makes problem easier to understand.
Comment 8 Mike Kaganski 2021-12-28 08:43:42 UTC
An empty paragraph is a case when its start equals to its end. It is treated specially for the "next style" purposes (see paragraph style's Organizer tab). But that doesn't change the fact that without the *current* behavior, users have no easy way of inserting text *before* images anchored to first paragraph. If we want to change also empty paragraph style's behavior to create impression of "moving", that's a different issue.

Clear NAB IMO.
Comment 9 Heesu Ban 2021-12-28 09:25:06 UTC
I attached two screenshot in #146139, for comparing.

In #146139, steps are 
1. open Writer document.
2. added Text Frame to an empty paragraph. Insert text in the Text Frame.
3. set cursor to first paragraph.
4. insert PARA_BREAK, PAGE_BREAK.
Comment 10 Aron Budea 2021-12-28 13:57:48 UTC
(In reply to Dieter from comment #7)
> I disagree, intention of bug 120469 was that object moves down, if paragraph
> moves down. I agree with that. But problem here is that - as far as I can
> see - paragraph doesn't move down. You can easily see that, if you assign a
> style to the first paragraph.
As Mike replied, the intention is that the paragraph should move down. I'm assuming that's the general user expectation in case of an empty paragraph, because there's nothing to keep. And yes, the style should also move, if it doesn't, I'd consider that an inconsistency.

The fact that this affects external programs calling into LO via UNO is an unfortunate side-effect. I wonder if/how other similar changes have been handled in the past, I'm sure there were several convenience changes before that could've had a similar kind of impact, eg. the change to default anchoring.
Comment 11 Mike Kaganski 2021-12-28 14:16:41 UTC
(In reply to Aron Budea from comment #10)
> The fact that this affects external programs calling into LO via UNO is an
> unfortunate side-effect. I wonder if/how other similar changes have been
> handled in the past, I'm sure there were several convenience changes before
> that could've had a similar kind of impact, eg. the change to default
> anchoring.

Note that the external program that we are discussing uses *cursor* API, i.e., the API which is intended to do the same as what user does with their cursor. Every API has some guarantee; for cursor, every programmer should realize that its guarantee is *to match UI behavior*. And that doesn't mean that that API disables each and every possible improvement in UI (just because such improvements can naturally change UI behavior) - it means that the API will follow the respective changes. So I believe that there's nothing "broken" in API, but someone could use it without realizing what it guarantees.

Instead, one could use paragraph enumeration to get the specific parts in the document, and then be completely independent from UI.
Comment 12 Heesu Ban 2022-01-11 14:37:55 UTC
It seems that this problem only occurs in external programs that use the API and does not occur to real users.
Since it only happens in empty paragraphs, I was able to solve this problem by adding space character right after adding shape.

It is the intended behavior, then we use the API accordingly. 
so I want to close this issue.