Description: While displaying the notes for slide 1, I begin a "find" command. Then I return to slide 1 and start another "find", but the search does not start at slide 1 or at the location of the previous found string. Steps to Reproduce: I first created a test presentation with the following three slides: Slide Title Slide Notes Slide 1 First page of notes This is the first slide of three Slide 2 Second page of notes This is the second slide of three Slide 3 Third page of notes This is the third slide of three 1. In the slide pane, click on the first slide. Click on the Notes tab to display the slide and its notes. 2. Choose Edit / Find, or press Ctrl-F. In the search box, type "second" (without the quotes) and press Enter. Slide 2 is displayed, and the word "Second" in the notes box is highlighted. This is correct. 3. In the slide pane, click on the first slide again. Choose Edit / Find, or press Ctrl-F. In the search box, type "of" and press Enter. Slide 3 is displayed, and the word "of" in the first line of the notes is highlighted. Actual Results: See above. The search for "of" in step 3 jumped to slide 3, skipping other occurrences of the search word. Expected Results: I expected the new search (step 3) to start from the current slide (slide 1) or maybe to continue from the last position on slide 2. Reproducible: Always User Profile Reset: No OpenGL enabled: Yes Additional Info: Version: 6.1.5.2 (x64) Build ID: 90f8dcf33c87b3705e78202e3df5142b201bd805 CPU threads: 4; OS: Windows 10.0; UI render: default; Locale: en-US (en_US); Calc: group threaded
Created attachment 149537 [details] Impress presentation as described in report.
I have tried various ways to force the second "find" to start at the first slide, but I haven't found a way that works.
Thank you for reporting the bug. I can confirm the bug present in Version: 6.3.0.0.alpha0+ Build ID: b6b28931435e44aca92b8c0e1659f701e3ed1a87 CPU threads: 2; OS: Windows 6.1; UI render: default; VCL: win; TinderBox: Win-x86@42, Branch:master, Time: 2019-01-30_06:57:04 Locale: en-US (en_US); UI-Language: en-US Calc: threaded
Not reproduced in Version 4.1.0.0.alpha0+ (Build ID: efca6f15609322f62a35619619a6d5fe5c9bd5a)
This seems to have begun at the below commit. Adding Cc: to Jan Holesovsky ; Could you possibly take a look at this one? Thanks bbc8dfb188adf653a3fe96b5bd23b06274a2161d is the first bad commit commit bbc8dfb188adf653a3fe96b5bd23b06274a2161d Author: Jenkins Build User <tdf@pollux.tdf> Date: Sat Dec 9 13:41:47 2017 +0100 source ed5450f2a5ed8e72b48b4d976217746cea04a5c9 author Jan Holesovsky <kendy@collabora.com> 2016-01-25 21:49:31 +0100 committer Jan Holesovsky <kendy@collabora.com> 2016-01-25 22:01:47 +0100 commit ed5450f2a5ed8e72b48b4d976217746cea04a5c9 (patch) tree f2847574a748202fc4a89cf4442424347bea4cb6 parent dcdc98b73601870a0d04a8d5253e56a4db59a266 (diff) sd lok: Fix normal 'search' performed after a 'search all'.
Dear David F Smith, 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://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
This bug is still present. There are no changes from the originally reported behavior. Version: 7.0.5.2 (x64) Build ID: 64390860c6cd0aca4beafafcfd84613dd9dfb63a CPU threads: 4; OS: Windows 10.0 Build 19041; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
repro 7.3+ The search is circular, so it seems like a very minor thing.
Comment 5's commit was followed up by https://cgit.freedesktop.org/libreoffice/core/commit/?id=9fc3d9b445d8c2bb8e259b42430cfe089642ab03 commit 9fc3d9b445d8c2bb8e259b42430cfe089642ab03 Author: Jan Holesovsky on Wed Mar 22 12:38:40 2017 +0100 lok sd: Fix crash when searching. This is a follow-up of ed5450f2a5ed8e72b48b4d976217746cea04a5c9 where the check for the HasView has been removed. Turns out that there are conditions when this really can happen, leading to crashes in the LOK searching. Unfortunately I did not manage to find a reliable reproducer to create a unit test :-( - so I suspect this commit might be more a workaround than a root cause fix. Would be great to find out the exact conditions leading to the situation when the EditEngine does not contain the EditView, and evaluate this fix against that - but that's hard without a reliable reproducer.
(In reply to raal from comment #5) > This seems to have begun at the below commit. I asked myself the question whether this ever worked. Running the bibisect again, I noticed that the first attempt to search for "of" just waited forever with a spinning cursor. Pressing "enter" to start the search a second time found the searched for item on the current slide - as expected. That has been true since at least LO 3.5, so this has never worked properly. It was kendy's commit that fixed the "waiting forever" on the first search attempt. Notes: -nothing special about the slide notes view. Also happens with normal slides. -doesn't happen if just stopping a find and restarting. Requires moving between slides before re-searching. That reinforces that search ought to start on the selected slide, and that this is a legitimate bug report.
proposed fix at http://gerrit.libreoffice.org/c/core/+/128729
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/b7d5ff4bbf41094b6579ae26023fbd686b060ce9 tdf#123658 sd search: partial UI unit test It will be available in 7.4.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.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/5f4ebedcd010f8248d9eea93bd36142a64820fe5 tdf#123658 sd search: restart search start on slide change It will be available in 7.4.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.