After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 710778 - "Next search result" caught in loop when using accelerator keys
"Next search result" caught in loop when using accelerator keys
Status: RESOLVED FIXED
Product: evince
Classification: Core
Component: general
3.10.x
Other Linux
: Normal normal
: ---
Assigned To: Evince Maintainers
Evince Maintainers
: 722702 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2013-10-24 08:39 UTC by Tobias Getzner
Modified: 2014-05-09 16:58 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch (14.80 KB, patch)
2013-10-27 15:44 UTC, Carlos Garcia Campos
none Details | Review
Updated patch (15.38 KB, patch)
2013-10-27 15:49 UTC, Carlos Garcia Campos
committed Details | Review

Description Tobias Getzner 2013-10-24 08:39:50 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
Comment 1 Germán Poo-Caamaño 2013-10-25 05:12:13 UTC
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.
Comment 2 Germán Poo-Caamaño 2013-10-25 05:14:31 UTC
It easy to reproduce with any PDF with multiple pages.  Using the mouse through the index page works, but not the accelerators.
Comment 3 Carlos Garcia Campos 2013-10-26 13:28:10 UTC
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.
Comment 4 Carlos Garcia Campos 2013-10-27 15:44:36 UTC
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.
Comment 5 Carlos Garcia Campos 2013-10-27 15:49:41 UTC
Created attachment 258225 [details] [review]
Updated patch

Forgot to add new symbol to the sections file.
Comment 6 Germán Poo-Caamaño 2013-10-27 16:55:18 UTC
It works for me.
Comment 7 Carlos Garcia Campos 2013-10-29 08:18:26 UTC
Thanks for testing, I've just pushed it to git master
Comment 8 Germán Poo-Caamaño 2014-05-09 16:58:51 UTC
*** Bug 722702 has been marked as a duplicate of this bug. ***