Download it now!
Bug 124356 - Shift key is accepted as input and clears cell content in KDE
Summary: Shift key is accepted as input and clears cell content in KDE
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
6.2.2.2 release
Hardware: All Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: KDE
  Show dependency treegraph
 
Reported: 2019-03-27 13:45 UTC by Owen Savill
Modified: 2019-10-30 03:39 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Owen Savill 2019-03-27 13:45:49 UTC
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.
Comment 1 raal 2019-03-27 19:36:30 UTC
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;
Comment 2 Owen Savill 2019-03-28 10:11:57 UTC
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
Comment 3 Owen Savill 2019-03-28 10:19:53 UTC
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?
Comment 5 Xisco Faulí 2019-03-28 12:06:54 UTC
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 6 Michael Weghorn 2019-03-28 16:54:56 UTC
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
Comment 7 Owen Savill 2019-03-29 13:45:43 UTC
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.
Comment 8 Michael Weghorn 2019-03-29 16:22:05 UTC
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, ...)
Comment 9 Owen Savill 2019-04-01 09:12:27 UTC
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.
Comment 10 Michael Weghorn 2019-04-01 15:12:59 UTC
(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...)
Comment 11 Owen Savill 2019-04-01 15:45:58 UTC
> 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.
Comment 12 Michael Weghorn 2019-04-02 11:02:32 UTC
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
Comment 13 Owen Savill 2019-04-04 12:35:27 UTC
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.
Comment 14 Michael Weghorn 2019-04-04 15:53:45 UTC
(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)?
Comment 15 Michael Weghorn 2019-04-04 19:21:30 UTC
Also, do you have any input methods (like ibus, fcitx) enabled?
Comment 16 Owen Savill 2019-04-18 12:20:35 UTC
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 *****
Comment 17 Michael Weghorn 2019-04-24 17:52:35 UTC
(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...)?
Comment 18 Owen Savill 2019-04-25 09:07:41 UTC
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.
Comment 19 Owen Savill 2019-04-30 11:59:24 UTC
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
Comment 20 Michael Weghorn 2019-04-30 18:26:48 UTC
(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.
Comment 21 Xisco Faulí 2019-05-02 07:26:17 UTC
(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...