I think this is a regression vs. Calc v6. Reproduction steps: 1. In a sheet, press Ctrl+F 2. Type "old text" 3. Press Enter. The text will or won't be found - doesn't matter. 4. Press Esc. (Here, the user would perform other operations in the sheet) 5. Press Ctrl+F again. 6. Type "new text" Expected result: "new text" is the text to search for, replacing "old text" Actual result: The search text is "new textold text" By contract, the Find and Replace dialog behaves as expected. If you press Ctrl+H at step 5, the "old text" WILL be selected, and typing "new text" will replace it. Also, if you skip Step 4 (pressing Esc) and press Ctrl+F again at Step 5, the "old text" WILL be selected. I think Ctrl+F should select the search text every time.
This was a problem one year ago and was solved. I have to search for a similar bug.
it's ok in Version: 7.0.0.3 (x64) Build ID: 8061b3e9204bef6b321a21033174034a5e2ea88e CPU threads: 4; OS: Windows 10.0 Build 19041; UI render: Skia/Raster; VCL: win Locale: ro-RO (ro_RO); UI: en-US Calc: threaded Try Help - Restart in Safe Mode - Factory Settings.
OK, checked that option (but not the two checkboxes under it), and restarted in Safe Mode. Same behavior.
Confirm with Version: 7.0.2.0.0+ Build ID: 5f305e6792c1c166b2a44a1e5085f42f53db50ea CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded The old text is not selected when searching for the new term. I am bibisecting now.
I can not bibisect this bug. I am getting this mesage: "f7830ce05114e975c7ea514438ee50ef180ffe65 was both good and bad"
In 7.0 oldest is good In 7.0 master is bad But I can not find the right answer.
236b1ede2ae1c72706b9a8d2c38be5b7e5a4e9e8 is the first bad commit commit 236b1ede2ae1c72706b9a8d2c38be5b7e5a4e9e8 Author: Jenkins Build User <tdf@pollux.tdf> Date: Thu Apr 16 20:38:50 2020 +0200 source bc0e0f633b05c4f91b6695488fc9e5c127507ba5 source bc0e0f633b05c4f91b6695488fc9e5c127507ba5 instdir/program/libvclplug_gtk3_kde5lo.so | Bin 3527968 -> 3533384 bytes instdir/program/libvclplug_gtk3lo.so | Bin 2400560 -> 2410064 bytes instdir/program/versionrc | 2 +- instdir/share/config/images_breeze.zip | Bin 1832522 -> 1832522 bytes instdir/share/config/images_breeze_dark.zip | Bin 1828136 -> 1828136 bytes instdir/share/config/images_breeze_dark_svg.zip | Bin 1501306 -> 1501306 bytes instdir/share/config/images_breeze_svg.zip | Bin 1498905 -> 1498905 bytes instdir/share/config/images_colibre.zip | Bin 2515159 -> 2515159 bytes instdir/share/config/images_colibre_svg.zip | Bin 2270737 -> 2270737 bytes instdir/share/config/images_elementary.zip | Bin 3995943 -> 3995943 bytes instdir/share/config/images_elementary_svg.zip | Bin 4899826 -> 4899826 bytes instdir/share/config/images_karasa_jaga.zip | Bin 4836086 -> 4836086 bytes instdir/share/config/images_karasa_jaga_svg.zip | Bin 18979388 -> 18979388 bytes instdir/share/config/images_sifr.zip | Bin 2022602 -> 2022602 bytes instdir/share/config/images_sifr_dark.zip | Bin 2024484 -> 2024484 bytes instdir/share/config/images_sifr_dark_svg.zip | Bin 1679671 -> 1679671 bytes instdir/share/config/images_sifr_svg.zip | Bin 1675909 -> 1675909 bytes instdir/share/config/images_sukapura.zip | Bin 2922273 -> 2922273 bytes instdir/share/config/images_sukapura_svg.zip | Bin 15254800 -> 15254800 bytes instdir/share/config/images_tango.zip | Bin 1751903 -> 1751903 bytes .../modules/swriter/ui/navigatorpanel.ui | 2 - .../share/config/soffice.cfg/vcl/ui/combobox.ui | 103 +++++++++++++++++++++ 22 files changed, 104 insertions(+), 3 deletions(-) create mode 100644 instdir/share/config/soffice.cfg/vcl/ui/combobox.ui
author Caolán McNamara <caolanm@redhat.com> 2020-04-09 11:41:00 +0100 committer Caolán McNamara <caolanm@redhat.com> 2020-04-16 20:28:24 +0200 commit bc0e0f633b05c4f91b6695488fc9e5c127507ba5 (patch) tree cca168c8aced9207ffa877693b856440764de341 parent de1dadd591862e38242cc2de7a4a658a9a8b67ac (diff) tdf#131120 use a replacement for GtkComboBox
Adding CC: to Caolán McNamara
i imagine we need gtk_widget_grab_focus instead of gtk_entry_grab_focus_without_selecting for the combobox then
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/bb6668bc596e62474ed2e1e923d9c9cd51685258 Resolves: tdf#136161 select all on grab-focus for GtkComboBox-alike widget It will be available in 7.1.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
fixed in master, backport to 7-0 in gerrit
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-7-0": https://git.libreoffice.org/core/commit/b365c09f2018eefe2ca8a5c138ae5fb6107175ec Resolves: tdf#136161 select all on grab-focus for GtkComboBox-alike widget It will be available in 7.0.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Solved. Verified in Version: 7.1.0.0.alpha0+ Build ID: e2f4e65a7b8024c00b049eebf0d87637efda7f24 CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded
Dan Dascalescu, thank you for reporting this bug.
Thank _you_ for the quick fix! 👌
*** Bug 134399 has been marked as a duplicate of this bug. ***
*** Bug 137218 has been marked as a duplicate of this bug. ***
GTK3 only, no possible to test it with a UI test
Thanks for the fix! Confirming correct behavior in 7.0.4.
How does this bug relate to bug 131120?