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
Created attachment 159766 [details] Example file
Repro with 4.4.7.2 no repro with LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4
No repro with Versie: 4.2.0.4 Build ID: 05dceb5d363845f2cf968344d7adab8dcfb2ba71
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)
(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
No repro with Version: 4.3.0.4 Build ID: 62ad5818884a2fc2e5780dd45466868d41009ec0
(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.
(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..
Note how tdf#124338 wants the opposite: that deleting the anchor in the text would delete the anchored object.
(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!!
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?
*** Bug 146451 has been marked as a duplicate of this bug. ***
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).
(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.
(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.
(In reply to Mike Kaganski from comment #15) > (bug , bug ) Sorry, missed numbers: bug 141161, bug 141162.
(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).
(In reply to Dieter from comment #17) > But what is the behaviour here? I see two possibilities: The behavior is the bug.
(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).
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.
(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.
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.
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 ***
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