Bug 112683 - Ctrl not traversing cells which contain only data if used with accessKey ‘v’ (paste)
Summary: Ctrl not traversing cells which contain only data if used with accessKey ‘v’ ...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
3.5.0 release
Hardware: x86-64 (AMD64) All
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Paste
  Show dependency treegraph
 
Reported: 2017-09-27 03:25 UTC by Óvári
Modified: 2024-06-01 03:15 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
accessKey (22.98 KB, application/vnd.oasis.opendocument.spreadsheet)
2017-09-27 03:26 UTC, Óvári
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Óvári 2017-09-27 03:25:33 UTC
Description:
See 'Steps to Reproduce'

Thank you

Version: 5.4.1.2
Build ID: ea7cb86e6eeb2bf3a5af73a8f7777ac570321527
CPU threads: 2; OS: Linux 4.10; UI render: default; VCL: gtk2
https://gerrit.libreoffice.org/gitweb?p=core.git&a=log&h=ea7cb86e6eeb2bf3a5af73a8f7777ac570321527

Steps to Reproduce:
Incorrect behaviour (and the reason for this bug ticket)
    1. Open “accessKey.odf”
    2. Select cell D3
    3. Press and hold the ‘Ctrl’ key
    4. Press and release the ‘c’ key (for copy)
    5. Press the downArrow key, i.e. ↓ or ▼
    6. Release the downArrow key
    7. Press and release the ‘v’ key (for paste)
    8. If warning dialog box “You are pasting data into cells that already contain data. Do you really want to overwrite the existing data?” appears, Select ‘Yes’ by pressing and releasing the ‘Enter’ key
    9. Repeat steps 5 and 8 to arrive at D24 (which does not happen)
    10. Release the ‘Ctrl’ key
The cells that are traversed are:
D3, D5, D7, D9, D11, D13, D15, D17, D19, D21, D23, D25
The cells that have data should only be traversed as the ‘Ctrl’ key is pressed.

Correct behaviour
    1. Open “accessKey.odf”
    2. Select cell D3
    3. Press and hold the ‘Ctrl’ key
    4. Press the downArrow key, i.e. ↓ or ▼
    5. Release the downArrow key
    6. Repeat steps 4 and 5 until you arrive at D24
    7. Release the ‘Ctrl’ key
Only cells with data are traversed, being:
D3, D5, D7, D9, D11, D13, D15, D18, D20, D22, D24

Actual Results:  
If accessKey 'v' (for paste) is used in conjunction with 'Ctrl' the amount of each movement remains as 2 (seems to be the first amount of movement) instead of moving to the next non-empty cell.

Expected Results:
Only cells with data should be traversed.


Reproducible: Always

User Profile Reset: No

Additional Info:


User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0
Comment 1 Óvári 2017-09-27 03:26:02 UTC
Created attachment 136559 [details]
accessKey
Comment 2 Xavier Van Wijmeersch 2017-09-27 07:03:38 UTC
I can not reproduce the behavior with

Version: 6.0.0.0.alpha0+
Build ID: bef91f7e5f3121dced360d4b90a09c334f12e56e
CPU threads: 8; OS: Linux 4.9; UI render: default; VCL: kde4; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2017-09-19_02:19:07
Locale: nl-BE (en_US.UTF-8); Calc: group

and

Version: 5.4.2.0.0+
Build ID: 61d85c4e7c30ea0f5242d927b7456190020b4fbe
CPU threads: 8; OS: Linux 4.9; UI render: default; VCL: kde4; 
Locale: nl-BE (en_US.UTF-8); Calc: group

The only thing i see is that the uppercase of the letter is not respected
Comment 3 Buovjaga 2017-11-07 16:44:18 UTC
Not reproduced, tried also with gtk2 VCL plug.

Arch Linux 64-bit, KDE Plasma 5
Version: 5.4.2.2.0+
Build ID: 5.4.2-2
CPU threads: 8; OS: Linux 4.13; UI render: default; VCL: kde4; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group

Arch Linux 64-bit, KDE Plasma 5
Version: 6.0.0.0.alpha1+
Build ID: f657454b69c813b90a8b3c1adb2feef1066dbd35
CPU threads: 8; OS: Linux 4.13; UI render: default; VCL: kde4; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on November 7th 2017
Comment 4 Óvári 2017-11-08 10:55:22 UTC
Retested and bug still present with:
Version: 5.4.3.1
Build ID: 32c8895c6cae21571f364dbb059f419a743ee44d
CPU threads: 2; OS: Linux 4.10; UI render: default; VCL: gtk2

In Steps to Reproduce:
Incorrect behaviour (and the reason for this bug ticket)
a) From step 3 the Ctrl key is pressed, held down and *not* released until to step 10
b) Does step 8 need to happen for this to be reproducible?

Thank you
Comment 5 Óvári 2017-11-08 10:58:02 UTC
If the message:
"This document is open in read-only mode."
shows, need to click on
'Edit Document'
Otherwise the bug is not reproducible.

Also the dialog box in step 8 needs to show. If you need a screenshot of this dialog box, please advise.

Thank you
Comment 6 Buovjaga 2017-11-08 13:52:28 UTC
My testing went exactly like you described. Just no problems.
Comment 7 Xisco Faulí 2018-01-09 11:25:05 UTC
Hi Óvári,
Could you please try to reproduce it with a master build from http://dev-builds.libreoffice.org/daily/master/ ?
You can install it alongsidethe standard version.
I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the master build
Comment 8 Óvári 2018-01-09 19:38:55 UTC
Retested and bug still present with:
Version: 6.0.0.1
Build ID: d2bec56d7865f05a1003dc88449f2b0fdd85309a
CPU threads: 2; OS: Linux 4.10; UI render: default; VCL: gtk2
Comment 9 Óvári 2018-01-09 19:45:22 UTC
(In reply to Xisco Faulí from comment #7)
> Hi Óvári,
> Could you please try to reproduce it with a master build from
> http://dev-builds.libreoffice.org/daily/master/ ?
> You can install it alongsidethe standard version.
> I have set the bug's status to 'NEEDINFO'. Please change it back to
> 'UNCONFIRMED' if the bug is still present in the master build

Version: 6.1.0.0.alpha0+
Build ID: acb43c0b8efbfb841e7b40603d75a8432eb21f21
CPU threads: 2; OS: Linux 4.10; UI render: default; VCL: gtk2; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2018-01-09_01:20:44

Cells traverse from D15 to D17
Cells should traverse from D15 to D18

Thank you
Comment 10 malboarg 2018-06-10 19:41:31 UTC
Thank you for reporting the bug. I can confirm that the bug is present in:

Version: 6.0.5.1
Build ID: 0588a1cb9a40c4a6a029e1d442a2b9767d612751
CPU threads: 2; OS: Linux 4.4; UI render: default; VCL: gtk2; 

The bug occurs when two contiguous cells (D16,D17) are empty, if I delete one of the rows (16 or 17), the app starts to behaves ok.
Comment 11 QA Administrators 2019-06-11 03:01:20 UTC Comment hidden (obsolete)
Comment 12 Óvári 2020-05-31 02:22:35 UTC
UX has been degraded further unfortunately as step 8 doesn't work now. Does not recognize Ctrl+Enter.

LibreOffice
Version: 6.4.4.2
Build ID: 3d775be2011f3886db32dfd395a6a6d1ca2630ff
CPU threads: 2; OS: Linux 5.3; UI render: default; VCL: gtk3

Linux Mint 19.3 Cinnamon 64-bit
Comment 13 Buovjaga 2020-05-31 18:21:54 UTC
(In reply to Óvári from comment #12)
> UX has been degraded further unfortunately as step 8 doesn't work now. Does
> not recognize Ctrl+Enter.

This seems unique for gtk3. No problem with kf5.

Btw. I reproduce the original problem. Not sure, why I didn't in 2017.
I also tried on Win with 3.3.0 and 3.5.0. Version 3.3.0 already flopped with moving after the second copy. 3.5.0 has behaviour that is identical to the current version.

Arch Linux 64-bit
Version: 7.1.0.0.alpha0+
Build ID: bfbf745470cb6f99532523fdeffca061b37d8393
CPU threads: 8; OS: Linux 5.6; UI render: default; VCL: kf5
Locale: fi-FI (fi_FI.UTF-8); UI: en-US
Calc: threaded
Built on 31 May 2020
Comment 14 QA Administrators 2022-06-01 03:36:25 UTC Comment hidden (obsolete)
Comment 15 Óvári 2022-06-01 09:45:41 UTC
(In reply to QA Administrators from comment #14)

Still happens with:

Version: 7.3.3.2 / LibreOffice Community
Build ID: d1d0ea68f081ee2800a922cac8f79445e4603348
CPU threads: 2; OS: Linux 5.4; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Flatpak
Calc: threaded

Instead of selecting ‘Yes’ by pressing and releasing the ‘Enter’ key, use the mouse and the ‘Enter’ key no longer works.
Comment 16 QA Administrators 2024-06-01 03:15:08 UTC
Dear Óvári,

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://web.libera.chat/?settings=#libreoffice-qa

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

Warm Regards,
QA Team

MassPing-UntouchedBug