Bug Hunting Session
Bug 47634 - Focus problem in text box with floating "Find" toolbar (gen/kde)
Summary: Focus problem in text box with floating "Find" toolbar (gen/kde)
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
3.4.5 release
Hardware: All All
: low normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 93267 (view as bug list)
Depends on:
Blocks: Find-Toolbar Floating-Menu
  Show dependency treegraph
 
Reported: 2012-03-21 01:41 UTC by Florent Angly
Modified: 2019-09-21 16:47 UTC (History)
10 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 Florent Angly 2012-03-21 01:41:17 UTC
I am experiencing an issue with LibreOffice Writer 3.4.5 (build 502) on Linux Mint Debian Edition (x86-64).

Focus problem with floating "Find" toolbar:

1. Open an arbitrary text document
2. Make sure the Find Toolbar is closed.
3. Press <control+f> to enable Find Toolbar
4. If the toolbar was previously undocked, the caret is still in the
document. (In constrast, if the toolbar was previously docked, the caret automatically moves to the search field.)
5/ Press Ctrl+F again to have the caret move to the search box (or move it manually there with a mouse).

So, the behavior of the focus is inconsistent with a docked or floating Find
Toolbar and should be made consistent. Several applications that I am used to
(Gedit, Firefox) automatically move the caret to the search box when a search
is requested. This is probably what should happen in the floating "Find"
toolbar as well in LibreOffice: the caret should automatically move to the search box when the Find Toolbar is opened.

Thanks,

Florent
Comment 1 Rainer Bielefeld Retired 2012-03-21 02:15:14 UTC
NOT reproducible with "LibreOffice 3.4.5 German UI [Build ID: OOO340m1 (Build:502)]" parallel Server installation on German WIN7 Home Premium (64bit). For me the caret always is in the undocked find Bar when it appears after <control+f>
Comment 2 Florent Angly 2012-03-21 17:59:05 UTC Comment hidden (obsolete)
Comment 3 Roman Eisele 2012-05-25 01:59:25 UTC
May be related to bug 49706 ?!
Comment 4 sasha.libreoffice 2012-06-14 02:14:58 UTC
not reproduced in 3.5.4 on Fedora 64 bit KDE4.6.5
May be fixed or specific for some particular desktop
Or I do something wrong
Comment 5 Florent Angly 2012-06-14 21:43:50 UTC
Still no luck with 3.5.4.2
Comment 6 Ben Woodcroft 2012-06-14 21:52:06 UTC
I was able to reproduce this using the current Ubuntu Precise current version, LibreOffice 3.5.3.2, Build ID: 350m1(Build:2)
Comment 7 Roman Eisele 2012-06-15 01:27:38 UTC
(In reply to comment #6)
> I was able to reproduce this using the current Ubuntu Precise current version,
> LibreOffice 3.5.3.2, Build ID: 350m1(Build:2)

OK, so the Status should be NEW now.

(In reply to comment #3)
> May be related to bug 49706 ?!

Forget this; but indeed this issue may be related to Bug 49853 - "EDITING: Cannot paste into 'find' box (OS X)". The latter is on MacOS X only, but also some kind of focus problem.
Comment 8 Florent Angly 2013-05-29 22:41:41 UTC
The problem is still apparent in LibreOffice version 4.0.3.3 (Build ID: 400m0(Build:3)).

By the way, it is not specific to Writer. Calc has the same issue (though it does not exhibit bug 49853).
Comment 9 Fr33Tux 2013-06-06 16:52:07 UTC
I meet the same problem with LO 4.0.3 and Linux Mint 14 x64. It occurs in Writer, Impress and Calc.
Comment 10 sasha.libreoffice 2013-06-07 05:07:50 UTC
Thanks for additional testing
Sorry, but "Version" is where bug appears. Not a current version of LO. If bug disappears, we just closing bugreport.
Changing back to 3.4.5.
Comment 11 Jean-Baptiste Faure 2013-06-12 04:53:56 UTC
Reproduced in 4.1.0.0.beta2+ (Build ID: e9c03d8225e79b63af6ab302e94fe08f2753a33) under Xubuntu 12.04 x86-64.
Exactly what reporter described: if the findbar is closed not docked, you need a second ctrl+F to get the caret in the search field.

Best regards. JBF
Comment 12 Octavio Alvarez 2015-02-25 20:04:27 UTC
Still present in 4.4.1.2, Ubuntu 10.04.1 LTS.
Comment 13 Florent Angly 2015-09-16 09:20:33 UTC
The bug is still present and even worse in 5.0.1.2.

Now the caret never moves to the field to enter a search term in the floating "Find" toolbar, no matter how many times I press ctrl+F. Even manually clicking on the field does not place the caret in the field, making the "Find" toolbar completely unusable. Luckily the toolbar still works well in its non-floating, docked form.
Comment 14 QA Administrators 2016-09-20 10:32:45 UTC Comment hidden (obsolete)
Comment 15 Jean-Baptiste Faure 2016-09-24 20:30:12 UTC
(In reply to Florent Angly from comment #13)
> The bug is still present and even worse in 5.0.1.2.
> 
> Now the caret never moves to the field to enter a search term in the
> floating "Find" toolbar, no matter how many times I press ctrl+F. Even
> manually clicking on the field does not place the caret in the field, making
> the "Find" toolbar completely unusable. Luckily the toolbar still works well
> in its non-floating, docked form.

Indeed. I see the same thing in LO 5.2.3.0+ under Ubuntu 16.04 x86-64.

Best regards. JBF
Comment 16 Timur 2017-09-05 12:56:36 UTC
*** Bug 93267 has been marked as a duplicate of this bug. ***
Comment 17 Timur 2017-09-05 12:59:09 UTC
This one was marked Linux but I'll set to All due to Bug 93267 I marked as duplicate. 

I can't repro in Windows but I repro these 2 issues: 
1. Ctrl+F to show docked find toolbar, then undock, focus is lost
2. set focus in undocked find toolbar and switch to other app outside LO and back, focus is lost
Comment 18 NichollsFam 2017-11-17 21:12:35 UTC
I'm currently using LibreOffice Version 5.3.1.2 on Kubuntu 17.04 and have the same problem still.  When the toolbar is docked, the focus moves to the toolbar whether it is visible or not, and regardless of whether Find is selected from the menu or Ctrl F is used.  When the toolbar is not docked and not visible, the focus stays in the document, again, regardless of whether Find is selected from the menu or Ctrl F is used.  If the undocked toolbar is visible, pressing Ctrl F takes the focus to the toolbar.
Why is this still a problem after 5 years????  I expect the focus to move to the toolbar the FIRST time I press Ctrl F.  I have been caught many times modifying my document when I actually want to search for something within my document.  It's annoying!
Please follow this up!
Comment 19 Xisco Faulí 2018-03-22 12:25:55 UTC
Still reproducible in

Version: 6.1.0.0.alpha0+
Build ID: 234d0368c823eb1a74e973e051ac522e6b86e833
CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: x11; 
Locale: ca-ES (ca_ES.UTF-8); Calc: group
Comment 20 Xisco Faulí 2018-04-06 09:06:54 UTC
This is not reproducible in gtk or gtk3...
Comment 21 Xisco Faulí 2018-04-06 09:08:13 UTC
Hi Bubli,
After fixing bug 116563 I thought you might be interested in this one...
Comment 22 Katarina Behrens (CIB) 2018-04-06 09:37:07 UTC
> Hi Bubli,
> After fixing bug 116563 I thought you might be interested in this one...

Well yesss, this is a generic a11y issue for all floats (toolbars and utility windows). They don't receive keyboard focus immediately after opening or being undocked in KDE4 and X11 frontend 

I wonder if we don't have a duplicate issue somewhere already
Comment 23 Jean-François Fortin Tam 2018-04-06 18:05:43 UTC
Random thought/suggestion: instead of a floating widget, how about using a GTK3 animated revealer container widget containing all the search-related functionality, that can then be dismissed with the Escape key and a close button, like what is standard in GNOME? Could be an opportunity to make it look nicer and better-integrated instead of just fixing the focus issue (and maybe spending a lot of time fighting around with window management)

Basically something more advanced than https://developer.gnome.org/gtk3/stable/GtkSearchBar.html based on https://developer.gnome.org/gtk3/stable/GtkRevealer.html (or maybe something else in GTK that I forget)
Comment 24 QA Administrators 2019-09-18 02:52:58 UTC Comment hidden (obsolete)
Comment 25 Jean-Baptiste Faure 2019-09-21 16:47:21 UTC
Not reproducible anymore for me with 

Version: 6.3.3.0.0+
Build ID: 154a9fc26890a34ac885f3191bf339b758c97936
Threads CPU : 4; OS : Linux 4.15; UI Render : par défaut; VCL: gtk3; 
Ubuntu_18.04_x86-64
Locale : fr-FR (fr_FR.UTF-8); Langue IHM : fr-FR
Calc: threaded


What about KDE ?

Best regards. JBF