Bug 123658 - When searching for a text string in slide notes, there is no obvious way to restart a search at the first slide.
Summary: When searching for a text string in slide notes, there is no obvious way to r...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
5.2 all versions
Hardware: All All
: low minor
Assignee: Justin L
URL:
Whiteboard: target:7.4.0
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Find-Search Notes-View
  Show dependency treegraph
 
Reported: 2019-02-23 04:22 UTC by David F Smith
Modified: 2022-02-05 19:46 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
Impress presentation as described in report. (11.47 KB, application/vnd.oasis.opendocument.presentation)
2019-02-23 04:23 UTC, David F Smith
Details

Note You need to log in before you can comment on or make changes to this bug.
Description David F Smith 2019-02-23 04:22:09 UTC
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
Comment 1 David F Smith 2019-02-23 04:23:15 UTC
Created attachment 149537 [details]
Impress presentation as described in report.
Comment 2 David F Smith 2019-02-23 04:24:35 UTC
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.
Comment 3 Durgapriyanka 2019-02-27 18:01:17 UTC
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
Comment 4 Xisco Faulí 2019-03-25 14:42:34 UTC
Not reproduced in

Version 4.1.0.0.alpha0+ (Build ID: efca6f15609322f62a35619619a6d5fe5c9bd5a)
Comment 5 raal 2019-03-25 21:53:18 UTC
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 sha: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'.
Comment 6 QA Administrators 2021-04-02 03:47:08 UTC Comment hidden (obsolete)
Comment 7 David F Smith 2021-04-02 19:39:29 UTC
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
Comment 8 Justin L 2021-11-23 16:42:11 UTC
repro 7.3+
The search is circular, so it seems like a very minor thing.
Comment 9 Justin L 2022-01-20 06:36:36 UTC
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.
Comment 10 Justin L 2022-01-21 08:04:20 UTC
(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.
Comment 11 Justin L 2022-01-21 12:19:18 UTC
proposed fix at http://gerrit.libreoffice.org/c/core/+/128729
Comment 12 Commit Notification 2022-01-31 09:44:11 UTC
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.
Comment 13 Commit Notification 2022-02-05 19:03:40 UTC
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.