Bug 101437 - UI: Shifted keyboard input deletes "click references" in formula input field (split/other window scenario only)
Summary: UI: Shifted keyboard input deletes "click references" in formula input field ...
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
5.2.0.4 release
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-08-10 16:37 UTC by Rickard Westman
Modified: 2018-08-18 07:34 UTC (History)
1 user (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 Rickard Westman 2016-08-10 16:37:50 UTC
I just upgraded to 5.2.0.4 from 5.1.x.x and noticed that "click references" together with manual keyboard entry works differently (and in my opinion worse) when editing/entering a formula in the input field.  

Previously, I could click a cell, type a few characters, click another cell, type a few more characters, and so on, with all the "click references" and typed characters being appended to the formula.  With 5.2.0.4, I sometimes see "click references" being replaced by what I type afterwards, unless I do something explicit to avoid it (like clicking an additional time in the input field or pressing the cursor-right key).  But it doesn't happen consistently that way!  

Examples:

1. A cell contains the formula "=A1+B2".  I click on the input field to edit the formula, type "+", click "C3", type "+", click 'D3'.  The result is "=A1+B2+C3+D3", which is just what I wanted.

2. A cell contains the formula "=A1+B2".  I click on the input field to edit the formula, type "+", click "C3", type "/", click 'D3'.  I would have wanted "=A1+B2+C3/D3", but instead get "=A1+B2+/D3" as the "/" replaced the click-inserted C3.

3. A cell contains the formula "=A1+B2".  I double click on the cell to edit the formula "in place" (not in the input field).  After moving the cursor to the end of the formula, I type "+", click "C3", type "/", click 'D3'.  The result is "=A1+B2+C3/D3", which is what I wanted.

So the behavior is different depending on which characters I type ('+' or '/'), and also depending on whether the cursor is in the input field or in the cell itself when I do the typing.
Comment 1 Buovjaga 2016-08-12 18:39:18 UTC
(In reply to Rickard Westman from comment #0)
> 2. A cell contains the formula "=A1+B2".  I click on the input field to edit
> the formula, type "+", click "C3", type "/", click 'D3'.  I would have
> wanted "=A1+B2+C3/D3", but instead get "=A1+B2+/D3" as the "/" replaced the
> click-inserted C3.

Could not reproduce. I get the correct result.

Maybe try https://wiki.documentfoundation.org/UserProfile#Resolving_corruption_in_the_user_profile

Set to NEEDINFO.
Change back to UNCONFIRMED, if the problem persists. Change to RESOLVED WORKSFORME, if the problem went away.

Arch Linux 64-bit, KDE Plasma 5
Version: 5.2.0.4
Build ID: 5.2.0-1
CPU Threads: 8; OS Version: Linux 4.6; UI Render: default; 
Locale: fi-FI (fi_FI.UTF-8)

Arch Linux 64-bit, KDE Plasma 5
Version: 5.3.0.0.alpha0+
Build ID: f2d09e621757fb5f394998afecba399b638f2428
CPU Threads: 8; OS Version: Linux 4.7; UI Render: default; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on August 12th 2016
Comment 2 Rickard Westman 2016-08-12 19:20:30 UTC
I just tried it with a deleted profile, and the problem remained the same.  

However, in reproducing the bug, I discovered that there is a factor I didn't mention but that is needed for the bug to occur: The window needs to be split for the bug to occur, and the "click reference" needs to be in the pane opposite to the formula cell.  In case there are more such factors that happen to be critical, here are some more detailed instructions on how to reproduce the bug:

1. Clear the user profile as per https://wiki.documentfoundation.org/UserProfile#Resolving_corruption_in_the_user_profile.

2. Create a new spreadsheet and size the window so that you see cells 1-28 vertically and cells A-K horizontally.

3. Mark row 14 and select "View / Split Window", so that the sheet is split in an upper and a lower part.

4. Mark cell A15 as active and enter "=A1+B1" followed by the return key.

5. Mark cell A15 as active and click at the end of the input/formula field.  Click C1, then type "/".  The "/" will now replace the C1 reference.  (Note that C1 is in the upper pane and the formula cell, A15 is in the lower pane.  If they are in the same pane, the bug does not show)

I'm running this on Ubuntu 14.04 using the default Unity desktop environment with libreoffice-gtk3 and libreoffice-style-galaxy installed.
Comment 3 Rickard Westman 2016-08-12 19:47:27 UTC
(In reply to Rickard Westman from comment #2)
> 5. Mark cell A15 as active and click at the end of the input/formula field. 
> Click C1, then type "/".  The "/" will now replace the C1 reference.  (Note
> that C1 is in the upper pane and the formula cell, A15 is in the lower pane.
> If they are in the same pane, the bug does not show)

The above step does trigger the bug, but has an unintended syntax error (a missing "+") that might confuse the issue.  The following works just as well to demonstrate the bug:

5. Mark cell A15 as active and click at the end of the input/formula field. 
Type "+", click C1, then type "/".  The "/" will now replace the C1 reference.  (Note that C1 is in the upper pane and the formula cell, A15 is in the lower pane. If they are in the same pane, the bug does not show)
Comment 4 Rickard Westman 2016-08-24 03:10:23 UTC
In addition to occuring with a split window, the bug also occurs when the clicked reference is in another window (showing the same document or another document).  It occurs with "click to focus" as well as with the "focus follows mouse" policy (using Compiz, the standard window manager in Ubuntu 14.04).
Comment 5 Rickard Westman 2016-09-09 09:23:37 UTC
Just upgraded to 5.2.1.2 and retested.  Results were the same.  I did not test a lot of variations this time, only the scenario in comment #2 with the correction given in comment #3.

Version: 5.2.1.2
Build ID: 1:5.2.1~rc2-0ubuntu1~trusty0
CPU Threads: 4; OS Version: Linux 4.4; UI Render: default; 
Locale: en-US (en_US.UTF-8); Calc: group
Comment 6 Buovjaga 2016-09-28 13:35:31 UTC
I tried again with the steps in comment 2 and 3, but / does not clear C1 for me. I even tried with forced gtk3:
SAL_USE_VCLPLUGIN=gtk3 libreoffice

Arch Linux 64-bit, KDE Plasma 5
Version: 5.3.0.0.alpha0+
Build ID: 7cf444454c0c27e2f6d764164ea880b87163f45a
CPU Threads: 8; OS Version: Linux 4.7; UI Render: default; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on September 27th 2016
Comment 7 Rickard Westman 2016-09-28 15:05:00 UTC
I just noticed an interesting thing: When I type the slash (/) using the number pad, the cell reference is *not* cleared, but when I type it using the main part of the keyboard, it is cleared as I described.  Same thing with asterisk (*).  For plus, minus, and period, it doesn't matter whether I type them using the number pad or not - the cell reference is not cleared.  

Experimenting some more, I realized that the relevant factor is actually if the keyboard entry is shifted or not.  The problematic input was all shifted on my (Swedish) keyboard while the unproblematic input was not.  So, for example, an uppercase 'A' clears the cell reference, while a lower-case 'a' does not.  

In fact, just pressing the shift key and releasing it afterwards triggers the problem for subsequent input, whether it's shifted or not.  The control key and "winmenu" key also triggers the problem, whereas the AltGr key does not.
Comment 8 Buovjaga 2016-09-29 18:26:04 UTC
(In reply to Rickard Westman from comment #7)
> Experimenting some more, I realized that the relevant factor is actually if
> the keyboard entry is shifted or not.  The problematic input was all shifted
> on my (Swedish) keyboard while the unproblematic input was not.  So, for
> example, an uppercase 'A' clears the cell reference, while a lower-case 'a'
> does not.  
> 
> In fact, just pressing the shift key and releasing it afterwards triggers
> the problem for subsequent input, whether it's shifted or not.  The control
> key and "winmenu" key also triggers the problem, whereas the AltGr key does
> not.

I experimented with the shift key, but did not see the problem.
I use Swedish layout (=Finnish), but a somewhat unusual keyboard (Truly Ergonomic). I should try on another machine..
Comment 9 Rickard Westman 2016-09-29 21:19:40 UTC
I realize Ubuntu 14.04 is a bit old at this point, and that my OS installation has accumulated quite a few tweaks and customizations over time.  So just in case something important was weird/unusual with my OS installation, I retested it on a fresh Ubuntu 16.04 installation before doing any tweaks/customizations at all (except adding the libreoffice PPA to get a new enough version - the standard one under Ubuntu 16.04 did *not* have the problem).

With a standard Ubuntu 16.04 and the libreoffice installed from the PPA, I could reproduce the bug just as described in the earlier comments.

Version: 5.2.1.2
Build ID: 1:5.2.1~rc2-0ubuntu1~xenial0
CPU Threads: 2; OS Version: Linux 4.4; UI Render: default;
Locale: en-US (en_US.UTF-8); Calc: group
Comment 10 Buovjaga 2016-10-16 10:29:48 UTC
Not reproduced on Windows either.

Win 8.1 32-bit
LibO Version: 5.3.0.0.alpha0+
Build ID: 970a66f8c919ea0524f216f40d21b3e2a8c88ccc
CPU Threads: 4; OS Version: Windows 6.2; UI Render: default; 
TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2016-10-16_00:03:17
Locale: fi-FI (fi_FI); Calc: group
Comment 11 Rickard Westman 2017-02-06 13:57:04 UTC
Just retested with 5.3.0.3 (under Ubuntu 14.04.5) and I can no longer reproduce the bug.  A number of Ubuntu libraries were updated at the same time, so I'm not sure whether the change that fixed the problem was actually in LibreOffice or in one of its dependencies.

Since I was the only one who could reproduce the bug while I saw it, I guess it should be closed, but I'm not doing it myself as I'm not sure what the proper resolution would be (FIXED, WORKSFORME, or something else?).

Version: 5.3.0.3
Build ID: 1:5.3.0~rc3-0ubuntu1~trusty1.1
CPU Threads: 4; OS Version: Linux 4.4; UI Render: default; VCL: gtk2; Layout Engine: new; 
Locale: en-US (en_US.UTF-8); Calc: group
Comment 12 Buovjaga 2017-02-06 14:03:00 UTC
Thanks. WFM, as we do not know the fix.
Comment 13 Rickard Westman 2017-12-31 13:15:34 UTC
Sadly, the bug reappeared after the last update, 10 months after it was fixed the last time (possibly by coincidence without knowledge of this bug report), so I'm changing the status REOPENED.  Let me know if a completely new bug report would be better.

My system details are the same (Ubuntu 14.04.5 with everything up to date) and the symptoms of the bug are exactly the same.  I haven't had time to test on a fresh Ubuntu install or with a cleared profile this time, though, but I note that the bug remained with a fresh install and a clear profile the last time.

This is the version of LibreOffice I'm running when I now see the bug:

Version: 5.4.4.2
Build ID: 1:5.4.4~rc2-0ubuntu0.14.04.1~lo1.1
CPU threads: 4; OS: Linux 4.4; UI render: default; VCL: gtk2; 
Locale: en-US (en_US.UTF-8); Calc: group
  
There were two LibreOffice updates appearing only days apart via the Ubuntu PPA, and I'm not sure whether this bug was present in the first of those updates (5.4.4.1?)  I'm sure I didn't see it between 5.3.0.3 and that version, though (and I do update LibreOffice regularly).
Comment 14 Rickard Westman 2018-01-14 18:55:53 UTC
Downgraded to 5.3.7.2, which was the closest previous version I could easily downgrade to, and the bug is not present there.

Version: 5.3.7.2
Build ID: 1:5.3.7~rc2-0ubuntu0.14.04.1~lo0
CPU Threads: 4; OS Version: Linux 4.4; UI Render: default; VCL: gtk2; Layout Engine: new; 
Locale: en-US (en_US.UTF-8); Calc: group
Comment 15 Buovjaga 2018-01-14 19:03:38 UTC
Hmm, maybe try with a 6.0 pre-release version as an AppImage: http://libreoffice.soluzioniopen.com/
It's an easy way to test, no need to install anything. Just make the AppImage executable and run it.
Comment 16 Rickard Westman 2018-01-14 19:23:16 UTC
(In reply to Buovjaga from comment #15)
> Hmm, maybe try with a 6.0 pre-release version as an AppImage:
> http://libreoffice.soluzioniopen.com/
> It's an easy way to test, no need to install anything. Just make the
> AppImage executable and run it.

Just tested the latest pre-release AppImage available at the link, and the bug is unfortunately there, using the test case described in comment #2 and #3.

Version: 6.0.0.2
Build ID: 06b618bb6f431d27fd2def25aa19c833e29b61cd
CPU threads: 4; OS: Linux 4.4; UI render: default; VCL: gtk2; 
Locale: en-US (en_US.UTF-8); Calc: group
Comment 17 Rickard Westman 2018-08-18 03:35:24 UTC
I have now tested with some newer AppImages, and I'm happy to report that the bug seemingly disappeared in version 6.0.5 and is still gone in 6.0.6 and 6.1.0.  So let's hope it doesn't reappear again!  Specifically, I tested these AppImages on Ubuntu 14.04.5:

  LibreOffice-6.0.3-x86_64.AppImage: Buggy
  LibreOffice-6.0.4-x86_64.AppImage: Buggy
  LibreOffice-6.0.5-x86_64.AppImage: OK
  LibreOffice-6.0.6.en-GB.help-x86_64.AppImage: OK
  LibreOffice-6.1.0.en-GB.help-x86_64.AppImage: OK

I also tested the 6.0.3 version that ships standard with Ubuntu 18.04, and it's buggy as well.
Comment 18 Buovjaga 2018-08-18 07:34:49 UTC
Great, let's set to WFM and hope it stays working!