Click on a cell and press the shift key. The cell content is wiped and the cell becomes blank. Clicking on the Edit menu shows Undo --> Input. Pressing the shift key alone shouldn't clear a cell.
I can not confirm with Version: 6.3.0.0.alpha0+ Build ID: 82463bdde75447d45e0cd6ed9ab579e0e51ea912 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3;
Version: 6.2.2.2 Build ID: 2b840030fec2aae0fd2658d8d4f9548af4e3518d CPU threads: 8; OS: Linux 4.20; UI render: GL; VCL: kde5; Locale: en-GB (en_GB.UTF-8); UI-Language: en-GB Calc: CL I've tried with a new profile and OpenCL both on and off. I'm running with KDE / Plasma 5
I don't seem to be able to get hold of 6.3-alpha, please could you supply me a link to download the deb packages?
https://dev-builds.libreoffice.org/daily/master/
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
FWIW, I cannot reproduce with the version used for the original report: 1) open new Calc sheet 2) click on cell A1 3) type "hello" 4) press Enter -> cursor jumps to A2 5) click on cell A1 again 6) press Shift Result in my case: nothing happens Version: 6.2.2.2 Build ID: 2b840030fec2aae0fd2658d8d4f9548af4e3518d CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: kde5; Locale: en-GB (en_GB.UTF-8); UI-Language: en-US Calc: threaded
I did what you described, i.e. created a new spreadsheet added content to a couple of cells then clicked on a cell and pressed Shift and it didn't clear the cell. So I saved and closed that document, didn't exit LibreOffice and opened the original Excel spreadsheet and the problem no longer occured. So I shut LO down and restarted. I opened the spreadsheet I had just created, clicked in a cell and pressed Shift - the cell cleared. So it appears that this bug is only present before you make any edits in a cell and / or the app is just opened.
I'm still unable to reproduce. Can you attach a spreadsheet for which this happens for you, and describe the steps to reproduce like this: 0) restart 1) open attached spreadsheet <NAME_OF_SPREADSHEET> 2) click on cell <CELL> 3) press Shift How exactly are you starting LibreOffice and opening the spreadsheet? (e.g. double click on the file in the file manager, opening the LibreOffice Start Center and then using "File" -> "Open" to select the file, ...)
I think this is another KDE / Plasma issue. > How exactly are you starting LibreOffice and opening the spreadsheet? (e.g. > double click on the file in the file manager, opening the LibreOffice Start > Center and then using "File" -> "Open" to select the file, ...) I've been trying to get LO 6.3 Aplha to not crash on startup on my system and was asked to run it with SAL_USE_VCLPLUGIN=gtk3 . When I start 6.2 with this set the issue no longer happens. I believe this implies it's a KDE / Plasma issue.
(In reply to Owen Savill from comment #9) > I've been trying to get LO 6.3 Aplha to not crash on startup on my system > and was asked to run it with SAL_USE_VCLPLUGIN=gtk3 . When I start 6.2 with > this set the issue no longer happens. I believe this implies it's a KDE / > Plasma issue. Yes, sounds like an issue with the kde5 VCL plugin then. Anyway, it'd still be interesting to have the question from comment 8 answered, to potentially allow other people to reproduce (and analyze) the issue. Feel free to attach a backtrace for the 6.3 alpha crash (you can get one by starting libreoffice with the '--backtrace' option (though it might be a good idea to move that to a separate bug then, but we can still do that when we have the backtrace...)
> Can you attach a spreadsheet for which this happens for you, and describe the > steps to reproduce like this: I can, it's pretty uninteresting. Just create a new spreadsheet, fill in a couple of cells and save and close it. On reopening from File --> Open the bug will be present. 0) Start LO 1) your new spreadsheet, or any spreadsheet 2) click on a cell with content, but don't double click or cause the entry cursor to appear in the cell. 3) press Shift and the cell contents will disappear.
Thanks for the info. I still cannot reproduce. Can you check whether the same thing happens if you test with a fresh LibreOffice profile? e.g. temporarily rename the $HOME/.config/libreoffice directory or start LibreOffice from command line using libreoffice -env:UserInstallation=file:///tmp/testprofile
Yes, it does. Opened for write a spreadsheet with content in cells A1 and B1. The first thing I did was press the Shift key and cell A1 was deleted. I have noticed that most meta keys do the same thing, those I've found so far are Tab, Ctrl, Alt, Alt Gr and both shift keys. LibreOffice knows a real edit has been made as it asks if it should save when the document is closed.
(In reply to Owen Savill from comment #13) > I have noticed that most meta keys do the same thing, those I've found so > far are Tab, Ctrl, Alt, Alt Gr and both shift keys. So instead of moving the selection one cell to the right, Tab clears the content of the current cell? That's really odd and I'm running out of ideas... What keyboard layout are you using? What distro and what architecture (x86/x86_64)?
Also, do you have any input methods (like ibus, fcitx) enabled?
Just installed 6.2.3 and it's still happening. > What keyboard layout are you using? Generic 101 key PC > What distro and what architecture (x86/x86_64)? Ubuntu 18.04, x86_64 > Also, do you have any input methods (like ibus, fcitx) enabled? **** Yes, IBUS was running. I've quit IBUS and have tried the same test repeatedly and the issue is no longer there. Re-enabling IBUS brings the issue back. So it looks like IBUS is the culprit *****
(In reply to Owen Savill from comment #16) > **** Yes, IBUS was running. I've quit IBUS and have tried the same test > repeatedly and the issue is no longer there. Re-enabling IBUS brings the > issue back. So it looks like IBUS is the culprit ***** What input method and mode have you set in IBUS? I quickly tried "German (German)" with "Direct Input" and "Japanese - Mozc" with Input Mode "Hiragana", but still couldn't reproduce. Any other relevant settings (I don't know much about input methods...)?
I'm no expert either, Actually I don't even know where it came from but I do know that if I stop the IBUS service key presses stop working in some apps so I think it's a Plasma thing. I'm currently using "English - English (UK, extended WinKeys)" and this is the only locale I have enabled. Don't know how the check the input mode unless that's the extended WinKeys bit.
Issue does not seem to be happening with Version: 6.3.0.0.alpha0+ Build ID: 6a67ecd9b12e68031b5dbacb591955b59f476b86 but is still happening in 6.2.3.2
(In reply to Owen Savill from comment #19) > Issue does not seem to be happening with Version: 6.3.0.0.alpha0+ > Build ID: 6a67ecd9b12e68031b5dbacb591955b59f476b86 but is still happening in > 6.2.3.2 OK, this might explain why I was unable to reproduce, even with IBUS enabled (I only tried master then). Can we mark this bug as WORKSFORME then, since it doesn't happen with the current development version any more? I quickly had a look at the kde-specific commits that are in 6.3.0.0.alpha0+, but not in 6.2, but none seemed obvious for having fixed this. It *might* even be it will be fixed with the upcoming 6.2.4.
(In reply to Owen Savill from comment #19) > Issue does not seem to be happening with Version: 6.3.0.0.alpha0+ > Build ID: 6a67ecd9b12e68031b5dbacb591955b59f476b86 but is still happening in > 6.2.3.2 Let's close it as RESOLVED WORKSFORME since this is no longer reproduced in master. Adding backportRequest to see when it got fixed...