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
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>
I have removed my existing LibreOffice and installed LibreOffice 3.5.1 (deb packages from http://www.libreoffice.org/download/, x86_64, English (US), LibreOffice 3.5.1.2, Build ID: dc9775d-05ecbee-0851ad3-1586698-727bf66). Now the floating Find Toolbar sometimes gets the focus, and sometimes not...
May be related to bug 49706 ?!
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
Still no luck with 3.5.4.2
I was able to reproduce this using the current Ubuntu Precise current version, LibreOffice 3.5.3.2, Build ID: 350m1(Build:2)
(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.
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).
I meet the same problem with LO 4.0.3 and Linux Mint 14 x64. It occurs in Writer, Impress and Calc.
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.
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
Still present in 4.4.1.2, Ubuntu 10.04.1 LTS.
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.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.1.5 or 5.2.1 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20160920
(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
*** Bug 93267 has been marked as a duplicate of this bug. ***
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
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!
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
This is not reproducible in gtk or gtk3...
Hi Bubli, After fixing bug 116563 I thought you might be interested in this one...
> 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
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)
Dear Florent Angly, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
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
Unlike some comments, repro in GTK3 with LO 7.1+. Version: 7.1.0.0.alpha0+ Build ID: 4a899a5f8a72ea29a6919316afe3627de9f33e95 CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US
Dear Florent Angly, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
This one is obsolete now. A newer issue is tracked in bug 148803.