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.
Most probably that's the fix to tdf#120469.
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
(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
(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.
Yes, that change was intentional, thus the behavior isn't a bug.
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.
(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.
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.
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.
(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.
(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.
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.