Steps to Reproduce: 1. Click on any autofilter dropdown. --> The focus is within the input box, that's good, we can now type in any text for quick search. 2. Move your mouse from the top entry (i.e. Sorting") down through the Filter by Color, then further down to the text Input Box. --> When mouse hover any other entry, that entry is focused (and if that entry has sub-entries then the sub-entries are popped up). This is good. --> However, when mouse hover on top of the text Input Box, the input box does not get focus, thus if you want to type anything into the text box then you need an extra click. This is annoying. Expected Result: In step 2, when mouse hover to the text input box, the text input box should get focus to allow quick input of text. Addition Info: Actually, at the time when the input box has not get focus, you actually can type, but the typing is not in the input box. It is in a "new" input box, and after you hit ENTER nothing take effect. Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: 64589ddc911ed7bcc334adecd46b472adfec15f2 CPU threads: 8; OS: Linux 5.14; UI render: default; VCL: gtk3 Locale: zh-CN (zh_CN.UTF-8); UI: zh-CN Build Platform: Fedora34@X64, Branch:master, bibisect-linux-64-7.4-CN Calc: threaded and also in Version: 7.3.0.0.beta1+ / LibreOffice Community Build ID: c25067e46d7d849a584295de365e32c6c7af11bf CPU threads: 8; OS: Linux 5.14; UI render: default; VCL: gtk3 Locale: zh-CN (zh_CN.UTF-8); UI: zh-CN Calc: threaded
Regression caused by the (great) improvements of hover-style autofitler submenus by Caolán in: commit 29145df0977baa866e7da94d1d385b772ae1e6ce Author: Caolán McNamara <caolanm@redhat.com> Date: Mon Nov 29 12:55:38 2021 +0000 Resolves: tdf#144811 use the hover-style menu for color submenus Caolán could you please take a look? Thanks.
I can confirm with Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: eee703970581545b56f3b2faa5b5911923ec28ea CPU threads: 4; OS: Linux 5.11; UI render: default; VCL: gtk3 Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US Calc: threaded Jumbo
*** Bug 147439 has been marked as a duplicate of this bug. ***
The following attachments from duplicate bug 147439 may help clarify what is happening since 7.3. Attachment 178282 [details] is a short video showing what happens in 7.2.5 (which is the correct behavior). The input box does not lose focus when the mouse hovers over the dialog. Attachment 178283 [details] shows what happens since 7.3, with the input box losing focus when it hovers over an entry with sub-entries.
The following attachments from duplicate bug 147439 may help clarify what is happening since 7.3. Attachment 178282 [details] shows what happens since 7.3, with the input box losing focus when it hovers over an entry with sub-entries. Attachment 178283 [details] is a short video showing what happens in 7.2.5 (which is the correct behavior). The input box does not lose focus when the mouse hovers over the dialog.
Another symptom: When opening Filter by Condition -> Standard Filter..., the focus is initially in the dialog, but is lost almost immediately. This is a regression from the same commit.
presumably the keyboard focus is initially in the GtkEntry, and when a submenu appears the keyboard focus is set there, so when the submenu pops down the focus is returned to the GtkTreeView parent of the submenu. Maybe we could check on the submenu popup where the keyboard focus is and return it to the GtkEntry if that's where it was before hand (for the common use case at least)