Created attachment 184509 [details]
Simple demo sheet

Hi Colin, I believe the problem has to do with hovering the mouse down over the "Search Items..." entry. If you move the mouse cursor over it, you won't be able to type anymore (no need to switch between applications). Can you please confirm that this is the bug you're experiencing?

This is a bug IMO... I've seen a ticket about it somewhere but can't find it anymore.

(In reply to Rafael Lima from comment #2)
> Hi Colin, I believe the problem has to do with hovering the mouse down over
> the "Search Items..." entry. If you move the mouse cursor over it, you won't
> be able to type anymore (no need to switch between applications). Can you
> please confirm that this is the bug you're experiencing?
> 
> This is a bug IMO... I've seen a ticket about it somewhere but can't find it
> anymore.

Hi Rafael,

Sorry, No. The effect is definitely dependent upon focusing outside the autofilter drop-down.

If I just meander through the Calc I get no hints or tips on any of the ribbon items but I do get mouse response when hovering over anything in the autofilter drop-down - just no keyboard response in the search box.

It returns to normal if I "close" the drop-down and reopen it

Version: 7.4.3.2 (x64) / LibreOffice Community
Build ID: 1048a8393ae2eeec98dff31b5c133c5f1d08b890
CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win
Locale: fr-FR (fr_FR); UI: fr-FR
Calc: CL

With my computer, I don't observe this bug.
It is still possible to continue typing text into the search box when I quit Calc to Google chrome and then return to Calc.

(In reply to Sophie Sipasseuth from comment #4)

> It is still possible to continue typing text into the search box when I quit
> Calc to Google chrome and then return to Calc.

Mine's Firefox - auto-updated to the latest version but I don't think it's browser related because I get the same issue if I just open a new local DocPad Document.
It isn't apparent in Excel which closes the autofilter pane the moment focus moves outside excel and the mouse button is activated in the "new" application

(In reply to Colin from comment #0)
> Steps to Reproduce:

(snip)
> Move your mouse cursor back to the "focused" search box and try to finalise
> the search criteria.
> You'll notice that the cursor bar re-animates the moment the mouse enters
> the zone but it will not permit interaction.

Even without changing to a different program, when I move the mouse to hover over some other area of the same filter such as "Filter be Condition > Empty" _without_ clicking on anything, the cursor stops blinking in the filter box. So, it is quite possible that under some condition, depending on "how" exactly the mouse moves (i.e. hovering on which exact area / artifact of your whole screen), the cursor within the filter area stops blinking.

I could also change to a different program; as long as I don't click on some other area within Calc, the filter box and the text I already typed-in within it are still available. All I have to do is to click on the end-side of the last typed-in character in order for the filter box to recover the focus.

Let me emphasize that: _clicking_ on the adequate place, I can continue with the filter box just where I left before.

If I misunderstood the problem, maybe I need some more clarification.

Version: 7.4.4.2 (x64) / LibreOffice Community
Build ID: 85569322deea74ec9134968a29af2df5663baa21
CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: default; VCL: win
Locale: en-US (es_AR); UI: en-US
Calc: CL

(In reply to ady from comment #6)

> Even without changing to a different program, when I move the mouse to hover
> over some other area of the same filter such as "Filter be Condition >
> Empty" _without_ clicking on anything, the cursor stops blinking in the
> filter box. So, it is quite possible that under some condition, depending on
> "how" exactly the mouse moves (i.e. hovering on which exact area / artifact
> of your whole screen), the cursor within the filter area stops blinking.

I wasn't really defining the lack of cursor blink as an issue as it has no impact but further experimenting to try to replicate what you infer has now identified that if I return to the filter pane and hover over either the text colour filter or the bbackground colour filter it pops out and remains out. If i then hover over the "other one" it pops out but retreats when moving on. It also appears to "ignore" the cursor when you again try to hover over the original source of the "locked" popout
 
> I could also change to a different program; as long as I don't click on some
> other area within Calc, the filter box and the text I already typed-in
> within it are still available. All I have to do is to click on the end-side
> of the last typed-in character in order for the filter box to recover the
> focus.

This is what I would expect if it worked properly in 7.3.7.2 are you aware of a partial fix - perhaps per @rafael lima comment 2 - already applied in 7.4.4.2

> Let me emphasize that: _clicking_ on the adequate place, I can continue with
> the filter box just where I left before.
> 
> If I misunderstood the problem, maybe I need some more clarification.

I'm unsure whether you're commenting as a developer seeking clarification, a user experiencing different symptoms or triaging my report and identifying that it's fixed in a later release.

(In reply to ady from comment #6)

It appears that both you and Sophie are on a later release so perhaps it has been eliminated by the missing report Rafael remembered but couldn't locate.

I've just tried it in Portable 7.4.3.2 and the popout freeze is fixed but the search items "feature" is still present.
> 
> Version: 7.4.4.2 (x64) / LibreOffice Community
> Build ID: 85569322deea74ec9134968a29af2df5663baa21
> CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: default; VCL: win
> Locale: en-US (es_AR); UI: en-US
> Calc: CL

I've now installed

Version: 7.4.5.1 (x64) / LibreOffice Community
Build ID: 9c0871452b3918c1019dde9bfac75448afc4b57f
CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win
Locale: sv-SE (en_GB); UI: en-GB
Calc: threaded

and tested with the uploaded example file  attachment 184509 [details] 

And it still fails to refocus  Search items.....

The freezing popups is no longer an issue - it's now a different structure

(In reply to Colin from comment #9)
> And it still fails to refocus  Search items.....

What happens if you click on the search box again when you hover over it? Can you continue typing-in?

(In reply to ady from comment #10)
> (In reply to Colin from comment #9)
> > And it still fails to refocus  Search items.....
> 
> What happens if you click on the search box again when you hover over it?
> Can you continue typing-in?

The search box resists all attempts to refocus. The only way to access it is to exit the pane and then reactivate it. I've tried double clicking and even a different mouse.

I also just deactivated all extensions that are not part of the LO download package - also to no avail

What I haven't tried is throwing the mouse against the wall - yet. Please advise if you would recommend that ;))

Bibisected with linux-64-7.2 to d4ed266849b558b041acb740a18bd81fa39bc582
tdf#133350 vcl focus loss: fix unwanted cancel of non-menu popup

Before this change, the search closed upon loss of window focus in all VCL UIs. After the change, Windows, gen and gtk3 UIs don't close the search.

Surprisingly, with gtk3 you don't have to refocus into the LibreOffice window in order to keep typing into the search input field.

Windows and gen require you to click somewhere else in LibreOffice, closing the search.

It seems Colin would like for gtk3's behaviour to become the new normal. Not sure what would be the best decision here, to go back or strive to make this new behaviour work in all UIs.

(In reply to Buovjaga from comment #12)
> 
> 
> It seems Colin would like for gtk3's behaviour to become the new normal. Not
> sure what would be the best decision here, to go back or strive to make this
> new behaviour work in all UIs.

I don't really have a preference. If the pane closes when focus moves away - as it does with many other pop-ups - then in my opinion, it's not malfunctioning.

There are undoubtedly ocassions when the user would want the pane to close and others where they only moved away to acquire further information to interact with that pop-up.

Is it feasible to try to identify when the pop-up would be more functional if it remained open for further information compared with "user has lost interest in this pop-up - move on"?

If the focus moves away and the pop-up remains, then having it function where it left off or even permitting a "change of heart" to activate an alternate item in the same popup seems logical. Then it would be the users'prerogative to continue, vary or abandon.

My understanding is that the following happened:

- f21d2b48bd68424a96aa6cd5572e368208378291 (tdf#121723 vcl: leave popup mode on focus loss of toplevel windows, 2018-11-26): see bug 121723, once we lost focus, there was a leftover menu item that I fixed

- d4ed266849b558b041acb740a18bd81fa39bc582 (tdf#133350 vcl focus loss: fix unwanted cancel of non-menu popup, 2021-03-29): 3 years later, see bug 133350, it was claimed that this change cancelling popups is not wanted in general, so I restricted the original change to menu items

- now this bug claims that the more broad canceling that was there between 2018-11-26 and 2021-03-29 (but not before, not after) is wanted.

I would claim that this is not a regression, since the wanted behavior had bad side-effects (see bug 133350).

If there is an agreement regarding if the behavior in bug 133350 or this bug is wanted, it's easy to act (either do nothing, or revert that oneliner change. I'm happy with either of these, as long as menus get cancelled on focus loss.

Colin: could you please talk to typingcat@gmail.com and reach an agreement on the wanted behavior? We certainly don't want to flip-flop on this further. Thanks.

Adjusting keywords accordingly.

Ok, so it seems the only thing to fix would be to make kf5 keep the search open like all the other UIs (not sure what happens on macOS).

(In reply to Buovjaga from comment #15)
> Ok, so it seems the only thing to fix would be to make kf5 keep the search
> open like all the other UIs (not sure what happens on macOS).

I think @Miklos Vajna may have formulated his request #14 to me before my response to you was published.

I still have no preference but I make the observation that if the pop-up is currently remaining open but not permitting interaction as per my original report and it is perceived by MV that the interaction has been terminated by focusing away from that pop-up - then the error is simply that the pop-up doesn't close. It's not a major issue to focus the slider again if it has been closed.

However, it would be a shame to close the pop-up if it can be fixed to allow the existing interaction to be continued. I don't believe that would be a conflict with the remediation already implemented for the other report.

In all honesty, I'm not sure I see the connection between losing control of a dropdown (menu?), in a selection in a menu bar, moved into an overflow situation and the report I made. A code module may have been re-used but the performance and expectation of the two "calling" items doen't really seem to be related.

Please advise if it is still considered that I should communicate with the cat.

I'm observing another variation in the interaction between the user's perceived focus between documents. I'm unsure whether it is a related "focus" issue, a new "feature" or simply a normal function of the operating system/LO.

Perhaps one of the big boys could advise whether I should file a new "feature" report or that it is indeed related - and pertinent.

If I am typing into a web page whilst a LO CALC file is loading, then upon completion of that load, the keyboard focus switches to the newly loaded CALC  and I discover the  latest characters of my current keyboard input in the "last active" cell of the CALC from the prior save.

It would be nice if the keyboard priority was unchanged and my editing efforts were entered into the currently active browser "document".