You are creating a clear dupe of bug 146443 - why? And additionally, that specific behavior was *asked for* in tdf#120469.

(In reply to Mike Kaganski from comment #1)
> You are creating a clear dupe of bug 146443 - why?

Because I could reproduce the problem in LO 7.0.6.2, but I couldn't reproduce problems described in bug 146443 wit LO 7.0.6.2. So I think, it couldn't be the same bug.

Ah, I might see the point: this one is "since 7.0" (actually since 6.4).

There are *two* changes around this.

1. In 7.0 (and backported to 6.4), there was https://git.libreoffice.org/core/+/a7528cd6f17ea5c5b29e7d607e54c62de0d9e7db, that explicitly aimed to anchor inserted images *to character* (as opposed to previous "to paragraph", with an intermediate "as character" moment during the development phase). That made images follow what was *always* the behavior of "to character"-anchored objects, which was move with its paragraph.

2. In 7.2, tdf#120469 was fixed, which made even to-paragraph-anchored images to follow the paragraph (if #1 would not happen, it would change here anyway).

Both are intentional, not a regression.

(In reply to Mike Kaganski from comment #3)
> 1. In 7.0 (and backported to 6.4), there was
> https://git.libreoffice.org/core/+/a7528cd6f17ea5c5b29e7d607e54c62de0d9e7db,
> that explicitly aimed to anchor inserted images *to character* (as opposed
> to previous "to paragraph", with an intermediate "as character" moment
> during the development phase). That made images follow what was *always* the
> behavior of "to character"-anchored objects, which was move with its
> paragraph.

Thanks for quick response and explanation. But problem is, that paragraph doesn't move, but anchor changes to new paragraph. I think this is only a problem in empty paragraphs (see further explanations in bug 146443 comment 7.

(In reply to Dieter from comment #4)
> But problem is, that paragraph doesn't move

This is just a flaky definition of "paragraph move" concept. See bug 120469 comment 4.

(In reply to Dieter from comment #4)
> (In reply to Mike Kaganski from comment #3)
> > That made images follow what was *always* the behavior of
> > "to character"-anchored objects, which was move with its paragraph.
> 
> But problem is, that paragraph doesn't move

Also excuse for the not completely correct phrase above. The behavior of to-character-anchored objects is actually to move *with its character* position, and that implied for empty paragraphs to move when pressing enter in that empty paragraph.

That doesn't change things much, just a clarification of #1.

(In reply to Mike Kaganski from comment #6)
> Also excuse for the not completely correct phrase above. The behavior of
> to-character-anchored objects is actually to move *with its character*
> position, and that implied for empty paragraphs to move when pressing enter
> in that empty paragraph.
> 
> That doesn't change things much, just a clarification of #1.
It does, as Dieter's comments are all related to paragraphs, eg.:

> (In reply to Dieter from comment #4)
> > But problem is, that paragraph doesn't move
Dieter, the image isn't anchored to a paragraph, but to character, as Mike has explained it. If you want to extend the description to include adjusting to To Paragraph anchoring, this is a duplicate of bug 146443.

(In reply to Aron Budea from comment #7)
> Dieter, the image isn't anchored to a paragraph, but to character, as Mike
> has explained it. If you want to extend the description to include adjusting
> to To Paragraph anchoring, this is a duplicate of bug 146443.

Perhaps my initial comment was not well formulated, but I've never talked about anchor "To Paragraph". It's of course anchor "To Character", but character is obviously part of a paragraph.


So I still think, that - from a user perspektive - it's an unexpected result. At least for the reason of consistency, you should get same result with an empty paragraph and a paragraph containing one character.

(In reply to Dieter from comment #8)
> Perhaps my initial comment was not well formulated, but I've never talked
> about anchor "To Paragraph". It's of course anchor "To Character", but
> character is obviously part of a paragraph.
You specifically mentioned paragraph in comment 4: "paragraph doesn't move, but anchor changes to new paragraph". The anchor doesn't change to the new paragraph, the anchor moves with the caret, just like a character after the anchor would move to the new paragraph if you hit Enter with the caret before it.

Also, if you set the anchor to To Character manually between steps 2 and 3 from the description, the behavior is the same in LO 3.3.0. Therefore this isn't a regression.

I understand, that initial bug report is misleading. So, to be more precise:

Steps to Reproduce:
1. Create a Writer Document and change style of first paragraph to "Heading 1" (not necessary, but makes more visible what's happening"
2. Insert an image. Anchor of image is "To Character" (Although it is not clear to me, what character is in an empty paragraph)
3. Set cursor to first paragraph.
4. Press Enter key several times.

Actual Results:
Anchor "To Chracter" is part of the new paragraph (still don't know what character) and image moves down.

Expected Results:
Anchor "To Character" should be still part of same paragraph (I assume, that - at least in normal text - a character is always part of a paragraph).

(In reply to Mike Kaganski from comment #6)
> The behavior of
> to-character-anchored objects is actually to move *with its character*
> position,

No problem with that

> and that implied for empty paragraphs to move when pressing enter
> in that empty paragraph.

But why is this a necessary behaviour? But I'm not a developer and I don't have to understand in detail. I just can't imagine, that a user expects, that new paragraphs are inserted above an image, if he presses enter in a paragraph below that image.

(In reply to Dieter from comment #12)
> > and that implied for empty paragraphs to move when pressing enter
> > in that empty paragraph.
> 
> But why is this a necessary behaviour?

It is not "necessary"; it is just how anchor to character is defined (the anchor is a special invisible "character" that is inserted *before* the anchored-to actual character); and that means, for empty character, that the inserted anchor is *before* ... what? it's before the paragraph end, which serves the anchoring point in this case. So when you put a cursor into an empty paragraph, it is *after* paragraph start, and *before* paragraph end; when you press Enter, you logically insert a "paragraph end - paragraph start" pair in the place where your cursor is, moving the existing old paragraph end to the following new paragraph; and since that moved paragraph end is the anchoring point, the anchored object moves accordingly.
But it is of course possible to special-case it as much as wanted ... just some clear unambiguous and non-confusing specification of expected behavior is needed.

> But I'm not a developer and I don't
> have to understand in detail. I just can't imagine, that a user expects,
> that new paragraphs are inserted above an image, if he presses enter in a
> paragraph below that image.

This is illogical. You are talking about the image being "above" paragraphs - and here you mix the anchoring with the orthogonal positioning; an image anchored to this character may be above or below, may have a fixed position on page, etc. This is not relevant to the discussion.

(In reply to Mike Kaganski from comment #13)
> and that means, for empty character, ...

Sorry, a typo: should be "and that means, for empty paragraph"

(In reply to Mike Kaganski from comment #13)
> and that means, for empty paragraph, that the
> inserted anchor is *before* ... what? it's before the paragraph end, which
> serves the anchoring point in this case. So when you put a cursor into an
> empty paragraph, it is *after* paragraph start, and *before* paragraph end;
> when you press Enter, you logically insert a "paragraph end - paragraph
> start" pair in the place where your cursor is, moving the existing old
> paragraph end to the following new paragraph; and since that moved paragraph
> end is the anchoring point, the anchored object moves accordingly.

Thank you for your detailed explanation. Just let me rephrase, what I understand and let me explain, why I still see inconsistency here and a need for an enhancement:

After inserting an image in an empty document, we have empty paragraph below document and order within this paragraph is: paragraph start | anchor | paragraph end
After placing cursor in that empty paragraph we have: paragraph start | cursor | anchor | paragraph end

Scenario A: press enter => paragraph break between paragraph start and anchor  => New empty paragraph before image (so this is, what you explained as expected behaviour and I can understand it now and therefore I won't consider the current behaviour a bug)

Scenario B:
Press spacebar (or any character) (Order within paragraph is: paragraph start | character (with connected anchor to character) | cursor | paragraph end)
Press Enter => New paragraph after the old paragraph and anchor to character is still part of the old paragraph (Expected)

So I think we can reduce problem to the question: To what should we anchor an anchor to character, if there is no character inside
a) paragraph start => with cursor we have order: paragraph start | anchor | cursor | paragraph end (I would prefer this solution)
b) paragraph end => with cursor we have order: paragraph start | cursor | anchor | paragraph end (current behaviour)
c) Not possible to have anchor to character in an empty paragraph

So let me give some resons for solution a)
1. Consisteny I: If we have anchor to (an empty) paragraph order seems to be: paragraph start | cursor | anchor (to paragraph) | paragraph end
2. Consistency II: Similar behaviour in an empty paragraph and in a paragraph after inserting a character.
3. User expectations: If there is an image with an empty paragraph below and user presses enter we can assume, that he would like to insert a new paragraph below the empty paragraph and not above the image (this is at least what he sees as a result).

So I would see it as enhancement, I've changed bug summary and added design-team for additional input.

(In reply to Dieter from comment #15)
> Just let me rephrase, what I understand

Your rephrase is very correct.

Only one, very specific problem in your following explanation (the UX problem itself, and the proposal that you suggest, looks OK to me):

> 3. User expectations: If there is an image with an empty paragraph below and
> user presses enter we can assume, ...

Please do *not* talk in terms of "below/above" in such cases. As I explained in the end of comment 13, the relative position of object and its anchor point is absolutely irrelevant. As soon as you try to define your proposal in terms of "user sees the image above the cursor -> they expect this or that" ... you create a huge inconsistency potential. If you suggest to make insertion of paragraph *before* the anchor when the anchor is the only paragraph contents, then it should be the only behavior: we must do it no matter if the image is above, or below, or to the left or to the right, when it's positioned absolute or relative ...

So please drop that "below". Or the result will quickly become even more confusing.

(In reply to Mike Kaganski from comment #16)
> If you suggest to make insertion of paragraph *before* the anchor ...

I'm sorry to create even more confusion. I meant to write "after" where I typed that "before". Sorry. So please read the above as

> If you suggest to make insertion of paragraph *after* the anchor ...

(In reply to Mike Kaganski from comment #16)
> So please drop that "below". Or the result will quickly become even more
> confusing.

Second try:

So let me give some resons for solution a)
1. Consisteny I: If we have anchor to (an empty) paragraph order seems to be: paragraph start | cursor | anchor (to paragraph) | paragraph end
2. Consistency II: Similar behaviour in an empty paragraph and in a paragraph after inserting a character.
3. Consistency III: There should be the same behaviour as in empty paragraphs without an anchor: New paragraph is inserted after the paragraph (So I assume, this is what users also expect for empty paragraphs with an anchor to character inside)

If the caret comes after the object it would become delete on backspace (see also bug 132321). Right now you can delete the empty paragraphs until the second (this is inconsistent as backspace on the very first empty paragraph does not delete but del does).

(In reply to Dieter from comment #15)
> c) Not possible to have anchor to character in an empty paragraph

Sounds logical to me: no character, no anchor. 

Having <space><image><space> allows me to delete both spaces as long one remains. And in case of <space><space><image><space><space> the image is highlighted if the middle section is selected. Very consistent, IMO.

It would be an improvement if the anchor would become a clear symbol for As/To Character.

(In reply to Heiko Tietze from comment #19)
> Sounds logical to me: no character, no anchor.
+1

> Having <space><image><space> allows me to delete both spaces as long one
> remains.
I confirm that. But that also means, that anchor changes to a different character, if the original character is deleted 8might be the expected behaviour; O.K. for me)

> And in case of <space><space><image><space><space> the image is
> highlighted if the middle section is selected.
I can't confirm that. Image is only highlighted, if I select all spaces (But I have no idea, how it is possible to see, that it is <space><space><image><space><space> or <space><image><space><space><space> or any other combination.)
 
> It would be an improvement if the anchor would become a clear symbol for
> As/To Character.
+1

But what is your conclusion for the current report: "If paragraph is empty, image should be anchored to paragraph instead to character?" I'm fine with that.

(In reply to Heiko Tietze from comment #19)
> Sounds logical to me: no character, no anchor. 

Well if you insert an object to empty page, and the default default anchor is 'to character', it must be anchored so.. So this actually should work, a contrary what the label might suggest.. 

And keep in mind why To Character became default...

--
> It would be an improvement if the anchor would become a clear symbol for
> As/To Character.

Maybe, but well the anchor is only visible if you have the image selected. And 'to paragraph' anchor is pretty obvious to detect; it's always anchored at the start of paragraph. To character anchor is mostly somewhere in the paragraph. 
Except if the document based on empty paragraphs.. 

I'm undecided if toggle formatting marks should have some marker for anchors

Off-topic side note: it's really hard to use 'to character' to anchor an image to specific word [or more specific a specific character of a word] + positioning the image with drag and drop. To character anchor kind of suggests control over the anchor, but well that's not exactly the case.

Created attachment 179940 [details]
Example file

I still think the current behaviour being correct.. I admit there are some cases where this actually suboptimal..

1. Open the attached file
2. Press backspace (nothing happens; related to step 7)
3. Press Enter.. -> Notice paragraph being created before the textbox. Also happening in Word
4. Undo everything
5. Type say 'A' character & press Enter -> position sticks (also in Word)
6. Press CTRL+Z to undo the new paragraph
7. Press backspace to delete the 'A' -> Textbox gets deleted). Not happening in Word.. But this should be covered by bug 148868

Above happens independent of anchoring type 'to paragraph' or 'to character'

(In reply to Telesto from comment #21)
> Off-topic side note: it's really hard to use 'to character' to anchor an
> image to specific word ...

Yse, completely off-topic, covered by tdf#141160, tdf#141161, tdf#141162.

(In reply to Dieter from comment #20)
> But what is your conclusion for the current report: "If paragraph is empty,
> image should be anchored to paragraph instead to character?" I'm fine with
> that.

As Telesto pointed out it's the only straight-forward solution in case of empty documents if we disable the type of anchor in empty paragraphs. The alternative is to accept the current situation, which is more or less clear as Mike explained. If the anchor symbol would become a "pointy anchor" it should be easier to understand.

So many if-then arguments but no clear recommendation from my side ;-).

(In reply to Heiko Tietze from comment #24)
> So many if-then arguments but no clear recommendation from my side ;-).

So who can decide in such a situation?

(In reply to Dieter from comment #25)
> So who can decide in such a situation?

As always, the do-er decides ;-). I would be afraid of messing up with the anchor, we likely missed side-effects, and rather change the indicator. WF could also be a resolution.

(In reply to Heiko Tietze from comment #24)
> As Telesto pointed out it's the only straight-forward solution in case of
> empty documents if we disable the type of anchor in empty paragraphs. The

But the empty documents is - I think - a rare example of what this report is about: an empty paragraph.

> alternative is to accept the current situation, which is more or less clear
> as Mike explained. If the anchor symbol would become a "pointy anchor" it
> should be easier to understand.

I didn't follow all comments - sorry - but has it been discussed that maybe a possible change is that the cursor is between the anchoring point and the paragraph marker?
Then pressing Enter would not move the anchor.

(In reply to Cor Nouws from comment #27)

> I didn't follow all comments - sorry - but has it been discussed that maybe
> a possible change is that the cursor is between the anchoring point and the
> paragraph marker?
> Then pressing Enter would not move the anchor.

Ah, but that is ~opposite to the behavior introduced in bug 120469

the behavior is odd - I do recognize it - but I see no sensible, always logic, way to improve that..?

(In reply to Cor Nouws from comment #27)
>... the cursor is between the anchoring point and the paragraph marker?

Comment 13 has some wisdom

The topic was on the agenda of the design meeting.

The current situation can be explained (comment 13) and is straightforward. Some may expect the object to move some want it to remain. And ultimately the discussion is somewhat academic anyway. So the recommendation is to keep the current behavior. => WF

*** Bug 149162 has been marked as a duplicate of this bug. ***

(In reply to Heiko Tietze from comment #31)
> The topic was on the agenda of the design meeting.
> 
> The current situation can be explained (comment 13) and is straightforward.
> Some may expect the object to move some want it to remain. And ultimately
> the discussion is somewhat academic anyway. So the recommendation is to keep
> the current behavior. => WF

And I disagree with current behavior and it's fully unclear for users now

*** Bug 139071 has been marked as a duplicate of this bug. ***

Created attachment 184510 [details]
Screencast (gif)

I aware reviving a bug isn't really appreciated. However the fix for bug 120469 is resulting in a disturbing user workflow, IMHO. The side-effects of the fix are not outweighing the benefits, if you ask. 
I do see bug 120469 as a valid request, though. However the side-effect are making me question if it should be fixed this way. I’m often in a fight with Writer. 

Press Enter with cursor at the beginning of paragraph with text or an empty paragraph, and image anchored to that paragraph, causes number of effect:

* adds paragraph above the image (surprise). Normally a paragraph being added below
* the cursor doesn't move; still at the bottom . Normally the cursor moves with to the newly created paragraph, so downwards (surprise).
* You can set Wrap to Optimal, the paragraph will go the side, but you’re unable to press Enter, to add additional paragraph next to the image
* You can't press Enter in table cell (to add paragraph below)
* Press ALT+ENTER below an image, will include the image (if the paragraph empty)

See screencast.

All those issues didn’t exist before the bugfix for bug 120469. 

------------
What is bug 120469 about. Idea: pressing Enter at the start of the paragraph (33 33) to move 33 33 down (creating an empty paragraph between 22 22 and 33 33) including moving the image anchor.  

Anchor will only be included if you place the cursor explicitly at the start of the paragraph. If you move cursor one step to the right (if text pressed) (LTR) & hit enter it will create paragraph below.

In case of empty paragraph start & end of the paragraph being the same thing. And Enter (to add new paragraph) is handled as if pressing Enter at the start of the paragraph. It’s always at the start of the paragraph. Without any means to switch to the ‘end’ position.
And pressing enter in an empty paragraph with image anchored to it isn't that uncommon.

By inserting a comment box into an empty paragraph, a distinction is made between, start & end of the paragraph. The paragraph is visually still empty, but the behavior changes. If you click inside paragraph with the mouse, you will be in ‘end’ position. Only if you press arrow left you move to ‘start’ of paragraph position.

I see two solutions:
A) revert the commit bug 120469 (this has been present for years :-)
B) Mimic the behavior, as if a comment comment box where present in the empty paragraph. In that case you really need to press arrow left to go beginning. This should be limited to case of empty paragraph. This would solve the issue in the majority of the cases.

(In reply to Telesto from comment #35)
> B) Mimic the behavior, as if a comment comment box where present in the
> empty paragraph. In that case you really need to press arrow left to go
> beginning. This should be limited to case of empty paragraph. This would
> solve the issue in the majority of the cases.

I still agree to Telesto and think it might be a solution, if technically possible (although it might be seen as an easter egg)

Setting to REOPENED for the time being (previous state: RESOLVED WONTFIX)

Removing UX as of comment 31

(In reply to Heiko Tietze from comment #31)
> The topic was on the agenda of the design meeting.
> 
> And ultimately the discussion is somewhat academic anyway. 

FWIW: It's not an academic question. The change has real-life workflow consequences. See comment 35. And for what's worth, not matching Word behaviour either

Multiple QA members and two bug reporters see the current state as undesired.

And well there is sentence in comment 13 (Mike) which suggests the issue being the lack of clear description of the bug. 

"But it is of course possible to special-case it as much as wanted ... just some clear unambiguous and non-confusing specification of expected behavior is needed."

I tried to demonstrate the problem in comment 35. And suggested a possible bugfix direction inspired by a corner case not fixed by bug 120469.

*** Bug 154429 has been marked as a duplicate of this bug. ***

*** Bug 154455 has been marked as a duplicate of this bug. ***

Noting that the behaviour started in 6.4 with commit d0aa2dbdf37aefe5b8d096fc5ea50cd13f87c5b0 (thanks Roman for pointing to it), and that Miklos was never part of the conversation.

Miklos, any opinion on it?

For what it's worth, I have to agree that the new behaviour of following the cursor when blank paragraphs are inserted has been bugging me for a while. It always felt like a bug to me.

I don't have a strong opinion on this, but it seems to me that bug 120469 was explicitly about introducing the current behavior and also our current behavior is in sync with what Word does. So if we change something here, there will be upset people.

If you want the image to not move on pressing enter, set its vertical position relative to the page, and then it will matter less where is the anchor.

*** Bug 141023 has been marked as a duplicate of this bug. ***

Same behaviour with achor to paragraph is described in bug 157617

*** Bug 157617 has been marked as a duplicate of this bug. ***

*** Bug 162799 has been marked as a duplicate of this bug. ***