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
Created attachment 136559 [details] accessKey
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
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
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
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
My testing went exactly like you described. Just no problems.
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
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
(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
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.
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 http://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 MassPing-UntouchedBug
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
(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
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
(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.