Description: Deleting a paragraph with backspace deletes the image (instead of moving up) Steps to Reproduce: 1. Open the attached file 2. Click on the second line 3. Press backspace -> Image gone 4. Undo 5. Go to the top paragraph & press delete.. image gone Actual Results: Image gone Expected Results: Moved up, not deleted by backspace Reproducible: Always User Profile Reset: No Additional Info: Version: 7.1.0.0.alpha0+ (x86) Build ID: 26483950760f0aac7bc45e93db4127f66a98fdc6 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL
Created attachment 161947 [details] Example file
Confirm it with: Version: 7.1.0.0.alpha0+ Build ID: cd47dba9aa4b91bb0edf0744561d29e2eef61cc9 CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2020-06-11_19:46:20 Calc: threaded
Created attachment 161991 [details] Writer doc. showing an issue withthe behaviour of paragraph-anchored imaghes Version: 6.4.4.2 (x64) Build ID: 3d775be2011f3886db32dfd395a6a6d1ca2630ff CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: default; VCL: win; Locale: en-GB (en_GB); UI-Language: en-GB Calc: threaded A similar problem: 1. Open the attached file. The image has been anchored to a blank paragraph. 2. Place the cursor at the start of the paragraph (where the image is anchored). Now add the text "abc" (for example). 3. Use the arrow keys to move the cursor before the "a". Use Shift + arrow, one press at a time. EXPECTED RESULT: When all three letters have been selected, the image should NOT be selected. ACTUAL RESULT: When all three letters are selected, the image is automatically selected as well. This is clearly anomalous because the image was able to exist on its own in the paragraph prior to the addition of the letters, whereas once the letters are added the image will be automatically deleted with the text. The user might expect that if ONLY the text is deleted, then the image, or frame, should remain. Reminds me of the problem in Bug 131331 (If you select paragraph in the header, selection includes a frame, that is anchored to that paragraph).
Created attachment 161993 [details] Example file A variant
(In reply to Telesto from comment #0) > Description: > Deleting a paragraph with backspace deletes the image (instead of moving up) > > Steps to Reproduce: > 1. Open the attached file > 2. Click on the second line > 3. Press backspace -> Image gone > 4. Undo > 5. Go to the top paragraph & press delete.. image gone > > Actual Results: > Image gone > > Expected Results: > Moved up, not deleted by backspace this is because with only 2 empty paragraph in the section, the selection created by Backspace or Delete key will be indistinguishable from one created by "select all". not sure how to fix that.
Regression introduced by: https://cgit.freedesktop.org/libreoffice/core/commit/?id=e75dd1fc992f168f24d66595265a978071cdd277 author Michael Stahl <Michael.Stahl@cib.de> 2019-12-05 16:49:33 +0100 committer Michael Stahl <michael.stahl@cib.de> 2019-12-06 14:44:42 +0100 commit e75dd1fc992f168f24d66595265a978071cdd277 (patch) tree 1e1870aac20c62254eb5b3b0f64711ea74730d54 parent 35191846feb19751e247cd228d7dcc6ddfdf2c8b (diff) tdf#121300 sw: consistent fly at-pargraph selection Bisected with: bibisect-linux64-6.4 Adding Cc: to Michael Stahl
(In reply to R. Green from comment #3) > > 1. Open the attached file. The image has been anchored to a blank paragraph. > 2. Place the cursor at the start of the paragraph (where the image is > anchored). Now add the text "abc" (for example). > 3. Use the arrow keys to move the cursor before the "a". Use Shift + arrow, > one press at a time. > > EXPECTED RESULT: When all three letters have been selected, the image should > NOT be selected. > ACTUAL RESULT: When all three letters are selected, the image is > automatically selected as well. > > This is clearly anomalous because the image was able to exist on its own in > the paragraph prior to the addition of the letters, whereas once the letters > are added the image will be automatically deleted with the text. https://bugs.documentfoundation.org/show_bug.cgi?id=132321#c16 is a similar scenario. i agree that this is inconsistent, but i think the way it should work is that if the entire section is selected, then all flys anchored in it are selected - even if the section doesn't contain any text, which is a special case that could be short-cut to do nothing previously. these commits implement this: https://gerrit.libreoffice.org/c/core/+/96324 https://gerrit.libreoffice.org/c/core/+/96350/
Michael Stahl committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/b314735568c1e9ab8ca52413017425bc2ef12973 tdf#132321 tdf#133957 sw: for at-para fly, ignore anchor SwIndex It will be available in 7.1.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/2d89b9929e85bede4c72684a12e7508751875f0e tdf#133957 sw: SelectAll should select fly in empty section It will be available in 7.1.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
*** Bug 133952 has been marked as a duplicate of this bug. ***
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-7-0": https://git.libreoffice.org/core/commit/eb6290410e699841b805ef75df393d72bf50baaa tdf#132321 tdf#133957 sw: for at-para fly, ignore anchor SwIndex It will be available in 7.0.0.1. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-6-4": https://git.libreoffice.org/core/commit/89dc2b547b4cc307f7d69715a5e1ed4a27691755 tdf#133957 sw: SelectAll should select fly in empty section It will be available in 6.4.6. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-7-0": https://git.libreoffice.org/core/commit/1ad7ff8affaba315c8f28a43a18d51c803eb78bc tdf#133957 sw: SelectAll should select fly in empty section It will be available in 7.0.0.1. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-6-4": https://git.libreoffice.org/core/commit/81580e8850a1f256262edeaea990fb40c0dd637f tdf#132321 tdf#133957 sw: for at-para fly, ignore anchor SwIndex It will be available in 6.4.6. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Not OK. I tested on Version: 7.1.0.0.alpha0+ Build ID: a3c8ea5e644ca2fc04de9f01ba9f8ace47f520f0 CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2020-06-17_02:21:20 Calc: threaded And it is not ok. The image is gone even it should be resolved.
Hi @Michael Stahl (CIB) : Could your commits be the Reason for Bug 137348 - picture pasted into new document (edit)? Thanks Ralf
(In reply to Telesto from comment #0) > Description: > Deleting a paragraph with backspace deletes the image (instead of moving up) > > Steps to Reproduce: > 1. Open the attached file > 2. Click on the second line > 3. Press backspace -> Image gone > 4. Undo > 5. Go to the top paragraph & press delete.. image gone > > Actual Results: > Image gone > > Expected Results: > Moved up, not deleted by backspace this is fixed now on master: keyboard backspace/delete shouldn't delete at-char/at-paragraph anchored objects (but should delete *as-char* objects of course). (In reply to R. Green from comment #3) > Created attachment 161991 [details] > Writer doc. showing an issue withthe behaviour of paragraph-anchored imaghes > > A similar problem: > > 1. Open the attached file. The image has been anchored to a blank paragraph. > 2. Place the cursor at the start of the paragraph (where the image is > anchored). Now add the text "abc" (for example). > 3. Use the arrow keys to move the cursor before the "a". Use Shift + arrow, > one press at a time. > > EXPECTED RESULT: When all three letters have been selected, the image should > NOT be selected. > ACTUAL RESULT: When all three letters are selected, the image is > automatically selected as well. > > This is clearly anomalous because the image was able to exist on its own in > the paragraph prior to the addition of the letters, whereas once the letters > are added the image will be automatically deleted with the text. > > The user might expect that if ONLY the text is deleted, then the image, or > frame, should remain. > > Reminds me of the problem in Bug 131331 (If you select paragraph in the > header, selection includes a frame, that is anchored to that paragraph). still disagree with this - an explicit selection should also delete anchored objects. this was always the case with objects anchored in fully selected paragraphs and now it happens if they are anchored in paragraph at start/end of selection too.
Michael Stahl committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/85376a02348810812d515ee72140dbf56f2b6040 tdf#133957 sw: don't delete flys on Backspace/Delete keys It will be available in 7.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Created attachment 180643 [details] Example file (In reply to Michael Stahl (allotropia) from comment #17) > still disagree with this - an explicit selection should also delete anchored > objects. this was always the case with objects anchored in fully selected > paragraphs and now it happens if they are anchored in paragraph at start/end > of selection too. I do grasp the annoyance/issue, I guess. 1. Open the attached file 2. Double click DEF to select it and type XXX. -> Intention replacing DEF for XXX. Result: shape gone The behaviour is as expect for cut/paste or copy/paste. Problems arise in (a) overwriting the selection (image gone, should remain) (b) hitting backspace/delete (intention is to delete the text, not the image, anchor should move to next character available character. Having exceptions for those situations would surely make the code more complex. But would be nice from the perspective of user experience, IMHO.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-7-3": https://git.libreoffice.org/core/commit/5192cd430e8cab0ed04f8c70c5194397455ac705 tdf#133957 sw: don't delete flys on Backspace/Delete keys It will be available in 7.3.5. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
hmm... the select-and-type-a-letter case looks very much like "replace"... i guess we could handle it in a similar way... you could of course also use the "Insert" key to go to overwrite mode, but i guess double-clicking to select words might have a certain convenience... however if you select the whole 100 page document and type a letter, you probably don't want any image to survive that? perhaps we could detect the case when the selection is inside one paragraph and treat that as "replace".
(In reply to Michael Stahl (allotropia) from comment #21) > hmm... the select-and-type-a-letter case looks very much like "replace"... i > guess we could handle it in a similar way... > > you could of course also use the "Insert" key to go to overwrite mode, but i > guess double-clicking to select words might have a certain convenience... The "select-and-type-a-letter case' not that different from backspace/delete case (in my perception). Backspace/delete could equal replace with nothing The position of a 'to character' anchor is currently pretty unpredictable. So pretty disturbing to delete image because the anchor got deleted. And end-user being in a fight with you're word processor to 'edit' some without deleting the image. > however if you select the whole 100 page document and type a letter, you > probably don't want any image to survive that? > > perhaps we could detect the case when the selection is inside one paragraph > and treat that as "replace". In the "select-and-type-a-letter case" I would shrug. Feels like over-optimizing.. How often does such a case occur? Ahum I'm cutting corners. Probably would bite me at some point. If 'delete/backspace' also included as 'replace' with nothing, you're suggestion should indeed be implemented.. Else you end up with image in document, where people likely would expect an empty document. -- Anyhow if you intended to change something here, please push a commit against new bug report. Addressing different issue in the same bug reporter is quite confusing.
Everything fine in Version: 7.4.0.0.beta1+ / LibreOffice Community Build ID: 6ab56a4fc946f6294513f23a3ea47aa0aa154b7d CPU threads: 16; OS: Linux 5.13; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded Thanks Michael for solving and Telesto for reporting.
*** Bug 132279 has been marked as a duplicate of this bug. ***