Bug 132279 - Deleting first paragraph of a document deletes anchored to object
Summary: Deleting first paragraph of a document deletes anchored to object
Status: RESOLVED DUPLICATE of bug 133957
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Anchor-and-Text-Wrap Writer-Images
  Show dependency treegraph
 
Reported: 2020-04-20 15:29 UTC by Telesto
Modified: 2022-08-12 06:56 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
Example file (12.65 KB, application/vnd.oasis.opendocument.text)
2020-04-20 15:30 UTC, Telesto
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2020-04-20 15:29:53 UTC
Description:
Deleting empty paragraph deletes anchored to object

Steps to Reproduce:
1. Open the attached file
2. Delete second last paragraph -> Graph disappears

Actual Results:
Graph disappears

Expected Results:
Anchor is invisible, so probably not. Word does never delete the object.. It always moves the anchor up


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 7.0.0.0.alpha0+ (x64)
Build ID: 4475bcd83aac7e033fc5250f268eb922bd471e7b
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: default; VCL: win; 
Locale: nl-NL (nl_NL); UI-Language: en-US
Calc: CL
Comment 1 Telesto 2020-04-20 15:30:05 UTC
Created attachment 159766 [details]
Example file
Comment 2 Telesto 2020-04-20 16:34:26 UTC
Repro with
4.4.7.2

no repro with
LibreOffice 3.3.0 
OOO330m19 (Build:6)
tag libreoffice-3.3.0.4
Comment 3 Telesto 2020-04-20 16:35:58 UTC
No repro with
Versie: 4.2.0.4 
Build ID: 05dceb5d363845f2cf968344d7adab8dcfb2ba71
Comment 4 Dieter 2020-04-22 09:01:33 UTC
This happens only, if image is anchored to character in the first paragraph of a document. If you delete the first paragraph in a document, anchor can't move up (as it dies normally in LO)

=> NEW (but I couldn't check regression)

Steps to reproduce
1. Open a new document
2. Add 4 empty paragraphs
3. Put cursor into third paragraph and add an image
4. Delete third paragraph => anchor jumps to second paragraph
5. Delete second paragraph => anchor jumps to forst paragraph
6. Delete first paragraph => Anchor and image disappears

Expected result: Not sure, perhaps change anchor to "To Page" (Don't know, if this is possible)
Comment 5 Telesto 2020-04-22 09:30:52 UTC
(In reply to Dieter from comment #4)
> Expected result: Not sure, perhaps change anchor to "To Page" (Don't know,
> if this is possible)

Anchor to character is the default (for images at least). See whole discussion bug 87720

STR where not precise enough, I guess
Steps to Reproduce:
1. Open the attached file
2. Delete last paragraph with backspace
Comment 6 Telesto 2020-04-24 21:25:35 UTC
No repro with
Version: 4.3.0.4
Build ID: 62ad5818884a2fc2e5780dd45466868d41009ec0
Comment 7 Buovjaga 2020-06-09 18:45:20 UTC
(In reply to Telesto from comment #5)
> STR where not precise enough, I guess
> Steps to Reproduce:
> 1. Open the attached file
> 2. Delete last paragraph with backspace

I am deeply confused. I repro with oldest of Linux 44max, 43max, 42max, 41max, 43all. In some of them the graph is invisible (blank?), but can be selected. It clearly disappears with the backspace however.

Telesto: maybe you can bibisect with the Windows 4.4 repo.
Comment 8 Telesto 2020-06-09 19:21:34 UTC
(In reply to Buovjaga from comment #7)
> I am deeply confused. I repro with oldest of Linux 44max, 43max, 42max,
> 41max, 43all. In some of them the graph is invisible (blank?), but can be
> selected. It clearly disappears with the backspace however.

Hmm, not gonna try. I'm assuming a inherent situation.. the regular case for anchoring to character issues..
Comment 9 Mike Kaganski 2021-08-19 09:13:48 UTC
Note how tdf#124338 wants the opposite: that deleting the anchor in the text would delete the anchored object.
Comment 10 Buovjaga 2021-08-19 09:24:37 UTC
(In reply to Mike Kaganski from comment #9)
> Note how tdf#124338 wants the opposite: that deleting the anchor in the text
> would delete the anchored object.

UX team: red alert!!
Comment 11 Heiko Tietze 2021-08-23 09:11:29 UTC
IMHO, safety first. MSO adds a step before deleting the image via backspace in that it becomes selected.

But MSO has no (obvious) anchor options as LibreOffice. In case of As Character, I expect objects to be deleted like any other character. To Character should mark the object on backspace at the very character and deletes then. It does right now nothing else but To Paragraph where the object is deleted as last "character".

In case of To Page anchored objects it shouldn't be deleted at all. The user should select this object. Luckily it's not a default option by any means.

Anything else to consider?
Comment 12 Dieter 2022-01-13 06:38:16 UTC
*** Bug 146451 has been marked as a duplicate of this bug. ***
Comment 13 Dieter 2022-01-13 06:39:00 UTC
While having a look at bug 146451 I came to this bug again and I understand it better now.

If you change anchor in attachment 159766 [details] from "To Character" to "To Paragraph" it jumps to second paragraph. And since it is not possible to delete first paragraph (AFAIK), you delete the second paragraph, if you press backspace (you can make it more visible, if first and second paragraph have different paragraph styles).

So I think we have to bugs here:
1. Anchor seems to be part of first paragraph but is in fact connected with second paragraph (I don't have a good formulation here)
2. It's not clear for users, that you can't delete first paragraph and therefor not clear that second paragraph (with anchor inside) will be deleted. Solution: Perhaps a window with a message like "It's not possible to delete the first paragraph of a document" (I assume somebody else will find a better solution).
Comment 14 Dieter 2022-01-13 06:41:10 UTC
(In reply to Mike Kaganski from comment #9)
> Note how tdf#124338 wants the opposite: that deleting the anchor in the text
> would delete the anchored object.

With reference to my previous comment 13 I don't see a conflict here. If it’s true, that anchor is connected in some way with the second paragraph and second paragraph is deleted instead or first paragraph, behaviour is in line with bug 124338.
Comment 15 Mike Kaganski 2022-01-13 07:29:49 UTC
(In reply to Dieter from comment #13)
> 1. Anchor seems to be part of first paragraph but is in fact connected with
> second paragraph (I don't have a good formulation here)

No. The anchor really *moves* when you change its type - it is re-created, and uses the object placement to find the closest text to anchor to. This is similar to other cases, like drag-and-dropping objects, where it not only changes object positioning, but also moves the anchor - and it's impossible to move only one, or the other, but not both (bug , bug ). So here there's no "seeming" position, the positions before and after the change are shown correctly, the change itself is questionable.

But the behavior of bug 146451 is unrelated to this bug, and you marked it a dupe to this one mistakenly: the objects anchored to *either* of the two initial empty paragraphs, both in to-char and to-paragraph modes, are deleted both when you press Del in 1st, or backspace in 2nd. That is an own issue.
Comment 16 Mike Kaganski 2022-01-13 07:31:03 UTC
(In reply to Mike Kaganski from comment #15)
> (bug , bug )

Sorry, missed numbers: bug 141161, bug 141162.
Comment 17 Dieter 2022-01-13 07:51:04 UTC
(In reply to Mike Kaganski from comment #15)
> No. The anchor really *moves* when you change its type - it is re-created,
> and uses the object placement to find the closest text to anchor to.
Thank you for explanation. I didn't know this.

> the positions before and after the change are shown
> correctly, the change itself is questionable.
I agree.

But what is the behaviour here? I see two possibilities:
1. Second paragraph is deleted instead of first paragraph. But that doesn't explain, why anchor is deleted too.
2. First paragraph is deleted and second paragraph takes paragraph style from first paragraph. But that wouldn't explain behaviour in bug 146451 (deletion of anchor in second paragraph)

I'm not a developer so excuse my (perhaps naive) question. But could somebody explain, what' actaully happening, if you try to delete first paragraph.

Additional observation: DF and CS of first paragraph (italic and underline) disappears, if you try to delete it (PS remains).
Comment 18 Mike Kaganski 2022-01-13 08:15:01 UTC
(In reply to Dieter from comment #17)
> But what is the behaviour here? I see two possibilities:

The behavior is the bug.
Comment 19 Mike Kaganski 2022-01-13 08:16:34 UTC
(In reply to Mike Kaganski from comment #18)
> The behavior is the bug.

Sorry, I meant to clarify that the behavior in bug 146451 is actual bug, so no explanation of what's happening there is necessary (and likely only possible when debugging).
Comment 20 Heiko Tietze 2022-03-11 07:44:03 UTC
We had this topic in the design meeting.

It's an unclear situation with WFM (comment 6) vs. never worked (comment 7) and bug 124338 requesting the opposite (comment 9). Starting with comment 13 the issue seems to be more complex.

In general, "As Character" should just delete, "To Character" mark/highlight the object first and a second backspace is required to actually delete (similar for "To Paragraph") and "To Page" should not delete at all unless explicitly selected.

If the object is anchored To Character and the whole paragraph is selected for deletion it would be a good idea to add the highlight step in this case as well. If the paragraph(s) have multiple objects attached this requires consequently to multi-select objects.
Comment 21 Mike Kaganski 2022-03-11 08:30:19 UTC
(In reply to Heiko Tietze from comment #20)
> In general, "As Character" should just delete, "To Character" mark/highlight
> the object first and a second backspace is required to actually delete
> (similar for "To Paragraph")

That looks reasonable and user-friendly. I'd like that.

However, is it discussed what happens when the removed part of text is *pre-selected*? I.e., you select a text piece with internal anchor (maybe including the whole paragraph), and press Del/Backspace. Should objects be selected either *and at what stage* in that scenario?

Additionally: what "mark/highlight" really means? Do you mean the normal graphic object selection, which may jump the view to the newly selected object? Consider that the object may be positioned *far* from its anchor - e.g., you may have it at the bottom of the page, when the anchor is currently at the top: you will not even see the object on screen when editing the paragraph. Pressing Backspace would suddenly select that object - if it jumps there, it would be unexpected/intrusive; if it doesn't jump, the behavior would be sudden disappeared text cursor, "ignoring" of the keypress (user would not see that pressing Backspace did something, since selection is outside of the screen), and would not help generally to resolve *this* issue discussed in this bug.
Comment 22 Heiko Tietze 2022-03-11 09:42:38 UTC
Tried to explain the consequences in the last paragraph. With mark/highlight I mean selection- actually the user feedback. If a paragraph contains anchors of one or more objects and those objects are not (yet) selected, this should happen first before the actual delete happens. The selection step is also needed if not all anchored objects are selected.

The major blocker is probably the multi-selection of objects (bug 121967 and other).

Alternatives: 

If the deleted object is out of view we could show an infobar. Otherwise, if the object is close to the deleted paragraph, you probably see what happens and undo is a click away. 

And last but not least, we could require to delete objects separately. Meaning the object anchored To Character / To Paragraph at the deleted paragraph remains visible (and anchored to the following paragraph) and you have to select every single object and delete it manually. Sound like excessive safety to me. 

To be honest, the whole topic sounds to me very constructed and has an unclear use case. Tend to NAB.
Comment 23 Gabor Kelemen (allotropia) 2022-08-10 17:36:42 UTC
This seems to be fixed in master since:

https://git.libreoffice.org/core/+/85376a02348810812d515ee72140dbf56f2b6040

author	Michael Stahl <michael.stahl@allotropia.de>	Tue Jun 07 19:01:24 2022 +0200
committer	Michael Stahl <michael.stahl@allotropia.de>	Wed Jun 08 20:31:40 2022 +0200

tdf#133957 sw: don't delete flys on Backspace/Delete keys

Also fixes: tdf#134007 tdf#138835 tdf#139514

*** This bug has been marked as a duplicate of bug 133957 ***
Comment 24 Dieter 2022-08-12 06:56:36 UTC
Yes, fixed in

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