GNOME Bugzilla – Bug 710778
"Next search result" caught in loop when using accelerator keys
Last modified: 2014-05-09 16:58:51 UTC
When searching for a term within a document in Evince 3.10.0, F3 resp. the "next hit" button loop over a subset of all hits. 1. Open https://www.gnu.org/software/automake/manual/automake.pdf 2. Search for "automake" 3. Keep F3 depressed. Result: Once page iv is reached, the search cursor loops between three hits on pages iv and v, despite that fact there are many more hits. Might be related to https://bugzilla.gnome.org/show_bug.cgi?id=710681
The index page is updated every time. However, the page with the selection is not. This is a regression. Search works as expected at least in 3.4.
It easy to reproduce with any PDF with multiple pages. Using the mouse through the index page works, but not the accelerators.
It happens when the search result is shown, but the current page is not the one where the search result is. We first set the page of the search result as current page, then we jump to find result, which calls ensure_rectangle_is_visible with the search result rectangle to make sure it's visible. That makes the view scroll to the search result. When scroll changes, the on_adjustment_value_changed is emitted, and the new best current page is calculated again based on the current scroll position. In some cases, the best current page is the previous one, so the current page is changed again. I think we can fix it by saving the page where the current search result is instead of using the current page, similar to what we do for caret cursor position.
Created attachment 258224 [details] [review] Patch I think this patch fixes all the regressions I have found in search. Please, test it to confirm it works.
Created attachment 258225 [details] [review] Updated patch Forgot to add new symbol to the sections file.
It works for me.
Thanks for testing, I've just pushed it to git master
*** Bug 722702 has been marked as a duplicate of this bug. ***