Created attachment 196676 [details] The file after pressing Backspace after the last field This was noticed in bug 150037 comment 11 1. Open bug 79435's attachment 100137 [details] 2. Click before/after any one of the fields and press Delete/Backspace -> the whole field disappears Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 4787fd4fc86230893a6da309f45964116b3a67df CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: hu-HU (hu_HU.UTF-8); UI: en-US Calc: threaded Seems to have started in 7.5, with commit: https://git.libreoffice.org/core/+/690d4eb71509649ad147cfe60f5b97e2cfaaa519 commit 690d4eb71509649ad147cfe60f5b97e2cfaaa519 [log] author Attila Szűcs <szucs.attila3@nisz.hu> Wed Jun 15 09:16:32 2022 +0200 committer László Németh <nemeth@numbertext.org> Mon Jul 04 15:34:57 2022 +0200 tdf#43100 tdf#104683 tdf#120715 sw: cursor on spaces over margin
I confirm the described behaviour, but I'mnot sure, that it is a bug. For me it seems, that if you place cursor before or after the field, field is deleted (maybe expected). If you place curosor before first character or after last character only this character is deleted. So problem might be, that you can't really see, where cursor is located. Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 8a6919f39b4b871904a2a4199755ca619aa707e2 CPU threads: 4; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: CL threaded Additional information Attachment 100137 [details] contains bookmarks, but result is the same with and without bookmarks.
(In reply to Dieter from comment #1) > I confirm the described behaviour, but I'mnot sure, that it is a bug. For me > it seems, that if you place cursor before or after the field, field is > deleted (maybe expected). I would not call it "expected", this was the main reason Justin reverted the patch of bug 150037 comment 6 in the gerrit linked at bug 150037 comment 11
(In reply to Gabor Kelemen (allotropia) from comment #2) > I would not call it "expected", this was the main reason Justin reverted the > patch of bug 150037 comment 6 in the gerrit linked at bug 150037 comment 11 Not really. I reverted the patch because clicking in a field and having all the (placeholder) text pre-selected should ONLY preselect the text and not the entire field. Somehow the field itself also needs to be deleted. So if the cursor is behind the field and you hit backspace, or before the field and you hit delete, then I would expect the entire field to be deleted.
(In reply to Justin L from comment #3) > Somehow the field itself also needs to be deleted. So if the cursor is > behind the field and you hit backspace, or before the field and you hit > delete, then I would expect the entire field to be deleted. Yeah, fair enough. On the other hand, in this case I'd expect the whole existing text (or placeholder) to be removed as well - unlike what I see on the image above. Maybe highlighting the whole field on first press, then deleting it all (text, fieldmark, bookmark) like Word does, could work here as well.
(In reply to Gabor Kelemen (allotropia) from comment #4) > (In reply to Justin L from comment #3) > > Somehow the field itself also needs to be deleted. So if the cursor is > > behind the field and you hit backspace, or before the field and you hit > > delete, then I would expect the entire field to be deleted. > > Yeah, fair enough. On the other hand, in this case I'd expect the whole > existing text (or placeholder) to be removed as well - unlike what I see on > the image above. > > Maybe highlighting the whole field on first press, then deleting it all > (text, fieldmark, bookmark) like Word does, could work here as well. Also, reverting to the pre-bibisect behaviour of removing existing content character by character is probably an option too, but maybe not the best.