Bug 36419 - EDITING: <Shift>+<Delete> does not work reliable as expected.
Summary: EDITING: <Shift>+<Delete> does not work reliable as expected.
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
(earliest affected)
3.3.2 release
Hardware: Other All
: medium minor
Assignee: Not Assigned
: 36101 (view as bug list)
Depends on:
Blocks: 36101
  Show dependency treegraph
Reported: 2011-04-20 04:32 UTC by Rainer Bielefeld Retired
Modified: 2021-04-25 04:02 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Note You need to log in before you can comment on or make changes to this bug.
Description Rainer Bielefeld Retired 2011-04-20 04:32:43 UTC
This is a spin off from
Bug 36418 - WIKIHELP: unexpected term "recycling bin"
Steps to reproduce the problem I found with  "LibreOffice 3.3.2  – WIN7  Home Premium  (64bit) German UI [OOO330m19 (Build:202 / tag]"

1. Open new Spreadsheet
2. Type "A", "B", "C" each into A1, B1, C1
3. Click on A1
   Cell cursor marks A1
4. <cntrl>+<c>
   Puts "A" into clipboard
5. Click A2
6. <cntrl>+<v>
   As expected, "A" inserted into A2 (and "A" still in clipboard)
7. Click on B1
   Cell cursor marks B1
8. Type <shift>+<delete>
   Expected: "B" put into clipboard, then disappears
   Actual: "B" disappears, also see 9. ff
9. Click A3
10. <cntrl>+<v>
   Expected: "B" from clipbard appears
   Actual: "B" appears

That's strange: I am 100% sure (now let me say 99%) that that did NOT work during my tests for 
Bug 36418 - WIKIHELP: unexpected term "recycling bin".
During those tests clipboard was not overwritten by <shift>+<delete>, but currently it works as expected 100%

My conclusion: Function not reliable. I will do further tests and try to make the unexpected behavior reproducible.
Comment 1 pierre-yves samyn 2011-04-21 00:32:29 UTC

This report includes part of what I wanted to point out in https://bugs.freedesktop.org/show_bug.cgi?id=36101

Shift+Del and Ctrl+X are expected to put marked contents to the clipboard and
then deletes it from the cell.

Cut and paste (or copy and paste) now works as Excel : after copying (cut) you can click on a destination cell and then press <Enter> to paste what was copied (cut). 

But actually <Shift-Delete><Entrer> *clears* the clipboard after pasting :

1.  Open new Spreadsheet
2.  Type "A", "B", "C" each into A1, B1, C1
3.  Click on A1
    Cell cursor marks A1
4.  <Ctrl>+<C> (blinking border)
5.  Click on A2
6.  <Ctrl>+<V>
    As expected, "A" inserted into A2 
7.  <Esc> (no more blinking border)
8.  Click on A3
9.  <Ctrl>+<V>
    As expected, "A" inserted into A3 ("A" still in clipboard)
10. Click on B1
11  <shift>+<delete>
    Expected: "B" put into clipboard, then disappears
10. Click on B2
11. <Enter>
    As expected, "B" inserted into B2
10. Click on B3
11. <Ctrl>+<V>
    Expected: "B" pasted in B3
    Actual : nothing happens, clipboard is empty

In brief :

- <Shift-Delete> and <ctrl+v> put the marked content in the clipboard and keeps it.
- <Shift-Delete> and <Enter> put the marked content in the clipboard for pasting and then clears the clipboard

What I expect:  That the text copied to the clipboard is kept regardless of the procedure

Nota : 

As i said in https://bugs.freedesktop.org/show_bug.cgi?id=36101, same problem with <Ctrl+C><Enter>

Anyway, the problem seems to me worse with cut and paste because of the defect reported here : https://bugs.freedesktop.org/show_bug.cgi?id=36100

Best regards
Comment 2 Rainer Bielefeld Retired 2011-06-22 22:07:37 UTC
Any Design hints concerning expected behavior? Is there any specification or similar?
Comment 3 Christoph 2011-07-17 10:55:38 UTC
(In reply to comment #2)
> @Christoph:
> Any Design hints concerning expected behavior? Is there any specification or
> similar?

Hi Rainer, no - there is no spec (referring to what I know). As far as I can see, these "dotted border" behavior is:
a) the very last thing I would have recommended to implement (in fact, it was always my example to explain that all OOo/LibO modules behave the same way, as every other application I know does - but Excel being the only inconsistent application in the universe)
b) It is only "half way" implemented. For example, the "dotted border" provides no explanation to the user what happens (e.g. Excel shows a hint in the status bar during that mode change).

In this case, I don't know what to suggest ... sorry.
Comment 4 Björn Michaelsen 2011-12-23 12:03:05 UTC Comment hidden (obsolete)
Comment 5 pierre-yves samyn 2011-12-24 02:37:30 UTC

Still persists with Windows 7 & LOdev 3.5.0beta2+ 
Build ID: 62b9587-7ef74e0-7bf1c81

Comment 6 retired 2013-03-29 01:08:49 UTC
*** Bug 36101 has been marked as a duplicate of this bug. ***
Comment 7 A (Andy) 2014-09-27 19:00:15 UTC
for me not reproducible with LO (Win 8.1)

Does this issue still persist for you or anybody else with the latest release of LO?  Otherwise, we could maybe close this issue as resolved.
Comment 8 pierre-yves samyn 2014-09-28 05:56:00 UTC

(In reply to comment #7)
> for me not reproducible with LO (Win 8.1)

I think you only have tested the Rainer's steps.

The Issue, described in comment 1, still persists on windows with Version:
Build ID: edfb5295ba211bd31ad47d0bad0118690f76407d

Comment 9 A (Andy) 2014-09-28 06:20:29 UTC
For me reproducible with LO as described in Comment 1, but not as described in Description.  But to reproduce it you need to press the ENTER key in Step 11, without this (only again using CTRL+V) it works as expected.
Comment 10 QA Administrators 2015-10-14 19:57:32 UTC Comment hidden (obsolete)
Comment 11 Buovjaga 2016-01-29 16:17:32 UTC
Repro comment 1.

Win 7 Pro 64-bit Version:
Build ID: 259c1ed201f4277d74dfd600fed8c837cbf56abc
CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; 
TinderBox: Win-x86@39, Branch:master, Time: 2016-01-27_00:45:12
Locale: fi-FI (fi_FI)
Comment 12 QA Administrators 2017-03-06 14:00:53 UTC Comment hidden (obsolete)
Comment 13 geraldg 2017-04-23 17:31:12 UTC
I checked under linux 5-3-2-2.
All works fine
Comment 14 Buovjaga 2017-04-23 17:40:16 UTC
(In reply to geraldg from comment #13)
> I checked under linux 5-3-2-2.
> All works fine

Contrary to this, still repro comment 1 on Win and Linux.

Version: (x64)
Build ID: 193f8966135064a32164c9da08d01dab9c1fc15d
CPU threads: 4; OS: Windows 6.19; UI render: default; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2017-03-25_02:08:45
Locale: fi-FI (fi_FI); Calc: group

Arch Linux 64-bit, KDE Plasma 5
Build ID: d69e6321fbb2c9f5b4d30890074a230ee6b39d2d
CPU threads: 8; OS: Linux 4.10; UI render: default; VCL: kde4; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on April 17th 2016
Comment 15 QA Administrators 2018-04-24 02:33:01 UTC Comment hidden (obsolete)
Comment 16 geraldg 2018-04-24 08:19:56 UTC
I checked under linux 6-0-4-1 (KDE).

Discription: All works fine
Comment 1 (insering with ENTER): The clipboard is empty after insering.
Comment 17 QA Administrators 2019-04-25 03:00:23 UTC Comment hidden (obsolete)
Comment 18 QA Administrators 2021-04-25 04:02:44 UTC
Dear Rainer Bielefeld Retired,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)

If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword

Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team