Bug 137113 - LO Calc Data - Validity - Cell Range / LIST - Selection List - Typing Selection is NOT working
Summary: LO Calc Data - Validity - Cell Range / LIST - Selection List - Typing Selecti...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
(earliest affected) release
Hardware: All All
: medium normal
Assignee: Not Assigned
Depends on:
Blocks: Cell-Validity
  Show dependency treegraph
Reported: 2020-09-29 07:04 UTC by pharmankur
Modified: 2021-10-11 18:36 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:
Regression By:

Demo File (10.49 KB, application/vnd.oasis.opendocument.spreadsheet)
2020-09-29 07:05 UTC, pharmankur
Screenshot - Dropdown with selection LO 6.4 (30.77 KB, image/png)
2020-09-29 07:06 UTC, pharmankur
Screenshot - Dropdown with selection ISSUE in LO 7.0.1 (73.91 KB, image/png)
2020-09-29 07:06 UTC, pharmankur

Note You need to log in before you can comment on or make changes to this bug.
Description pharmankur 2020-09-29 07:04:14 UTC
Recently updated to LO 7.0.1
I found following
LO Calc Data - Validity - Cell Range / LIST - Selection List - Typing Selection is NOT working in LO 7.0.1

When validation is given and drop-down is allowed, and when a key say "M" is pressed, the option starting with "M" used to get selected till LO 6.4.6

But in 7.0.1 it is not getting highlighted and we have to manually scroll to desired option.

This slows down working with drop-down selections.

Demo file is attached
Screenshot it enclosed for version 6.4 (Where it was working as desired) & 7.0 (where there is issue)

Steps to Reproduce:
1. Open LO 7.0.1
2. In Calc LO Calc Data - Validity - Cell Range / LIST - Selection List
3. Give any valid cell range / list (e.g. A,B,C,...,Z)
4. In the dropdown press any key e.g. "M" 

Actual Results:
Nothing happens , M is not highlighted from drop down

Expected Results:
"M" from drop-down should get highlighted and if Up and Down arrow, highlight should change, and if pressed Enter, the highlighted option should get selected in the cell

Reproducible: Always

User Profile Reset: No

Additional Info:
Was working fine till LO 6.4.6
This appears only in 7.0 onward.
Comment 1 pharmankur 2020-09-29 07:05:10 UTC
Created attachment 165934 [details]
Demo File
Comment 2 pharmankur 2020-09-29 07:06:18 UTC
Created attachment 165935 [details]
Screenshot - Dropdown with selection LO 6.4
Comment 3 pharmankur 2020-09-29 07:06:55 UTC
Created attachment 165936 [details]
Screenshot - Dropdown with selection ISSUE in LO 7.0.1
Comment 4 m.a.riosv 2020-10-02 17:36:53 UTC
Confirmed, begin showing the last values.
Version: (x64)
Build ID: dec9a123867dcd0fea4683beeb3b4b6659f926f3
CPU threads: 4; OS: Windows 10.0 Build 20180; UI render: Skia/Vulkan; VCL: win
Locale: es-ES (es_ES); UI: es-ES
Calc: threaded
Comment 5 Grobe 2021-10-10 13:40:32 UTC
Confirm issue on:

Build ID: 10(Build:2)
CPU threads: 2; OS: Linux 5.14; UI render: default; VCL: gtk3
Locale: nb-NO (en_US.UTF-8); UI: en-US
Calc: threaded

OS: Linux Fedora 34 with Gnome desktop.

In my case, there are a validadtion range where the majority of the valid cells begin with two numbers and a space, followed by text. The last data cell begins with 32 (around 45 in total).

Say I want to use the keyboard to select "17 X4". The steps to follow:
* Select the cell C20 (in this particular spread sheet) (do not go into edit mode)
* Hit keyboard Alt + Down. The list of possible choises appear.
* Then hit keyboard 17 and Enter.

Expected behaviour: The cell should now contain the text string "17 X4".

Observed behaviour: Another text (from the validity list) appears instead. Even that I can see that the blue marker selects the item containing "17 X4".

Reproducible: Sometimes.
Yes, unfortunately I don't know how to make sure to reproduce this. Seems that if I make another application active, and then comes back to Calc, the problem suddenly dissappear.

To me, it seems that this behaviour goes periodically. It seems that when the behaviour is bug=activated, Calc fails to insert correct value almost every time, no matter what value I choose.
When there is a period where bug=inactive, it seems that Calc work correctly on seemingly every values I enter from validity list.

The big problem is when I find my workflow where I'm about to enter houndreds of items from validity list, I don't always check if the actual value in the cell is correct. I just now had a case where I had to re-check every single input all over again because of this bug.
Comment 6 Grobe 2021-10-10 14:40:09 UTC
I think I know what causes this behaviour now.

In my case, the only cells that have input restrictions (validity from range) are limited to column C.

In coloumn A, is some key data.

Both column A and C may be filtered.

So it turns out that:

When there is a FILTER ON for column A, then Calc will fail inserting the correct value when using method Alt+Down + <short keyboard input here> + Enter on a visible cell in coloumn C.

When there is NO FILTER for column A, then the mentioned method seems to work flaweless every single time.

Hope this helps, and hope you guys are able to fix this annoying issue.
Comment 7 Grobe 2021-10-11 18:36:22 UTC
Tested again today.

Unfornately after I tested some more, my previous assumption turned out being wrong, please disregard my last post.

Today I was attempting to record the screen to show what it appears like, but I had to log in using X11 instead of Wayland to be able to record the screen.

Then I observed that while under X11 I was not able to reproduce at all. However, I found a new behaviour under X11 - on some cells, after hitting Alt + Key Down, Calc would simply not respond to any normal keyboard inputs until selected something else (either from the validatidy list or another cell).
After this behaviour for typical three to five times, it all of a sudden behaved normally again.

After logging out and into Wayland (the default for Fedora), I was able to reproduce the behaviour of Calc inserting some wrong value from validity list.
However, the behaviour seems very inconsistent.
It appear to have some behaviours in addition:
* Can react (slightly tendencys to trigger the behaviour when) to resizing of windows, or activate some other programs and then going back to the Calc window.
* More probably happens if the program window is not maximum size.

Also observed when on Wayland: When Calc window are made smaller and placed in the upper part of the screen, the little box that review the keyboard input have a tendency of placing itself much lower on the screen and way outside the Calc window.