GNOME Bugzilla – Bug 697194
Search in PDFs is broken
Last modified: 2013-04-20 15:52:09 UTC
A few things are wrong with evince's new search function. * Hit Ctrl-F, enter a serch term that is *not* on the current page. Then, a number of different things may happen: * The search form may disappear * evince may crash * Everything may work just fine. It's possible to force things to go wrong by repeatedly hitting Enter. For definiteness, you may try this by searching for "arc-length" in http://arxiv.org/pdf/1212.3868v1
Created attachment 240507 [details] gdb session Indeed, the behaviour gets annoying shortly. I also searched for 'expansion', which appears in plenty of pages. The search bar keeps there as long as there are matches in the current or immediately next page. Once there are not, the search bar gets hidden and once find himself hitting enter in the document rather than the search bar. FWIW, the first time I could reproduce the bug quickly. With gdb I had to try several times. I am not sure I triggered exactly the same issue twice or a different one. Anyhow, the gdb session is attached.
I forgot to add: I reproduced it with: - evince master (3d2d338e087) + patches from https://bugzilla.gnome.org/show_bug.cgi?id=695524 - poppler master (4ee6757dd7) (slightly newer than 0.22)
An updated stacktrace. This makes more sense to me. Starting program: /home/gpoo/code/evince/install/bin/evince '/home/gpoo/Descargas/epiphany/1212.3868v1.pdf' [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1". [New Thread 0xb5669b40 (LWP 9014)] [New Thread 0xb4cffb40 (LWP 9015)] [New Thread 0xa7398b40 (LWP 9020)] [New Thread 0xa69ffb40 (LWP 9021)] [Thread 0xb4cffb40 (LWP 9015) exited] Program received signal SIGSEGV, Segmentation fault.
+ Trace 231721
Thread 2795502400 (LWP 9021)
So this is a threading issue... yeah! I believe the problem is the following (not sure...): 1. You search for a term. 2. you hit enter until you are in the last match of the page. 3. you hit enter once more and the next match is in a page which is not cached. 4. since the page is not cached, we get the loading... overlay, which gives focus to the ev_view. 5. since the find_bar losts its focus, it hides itself.
The loading window is not a window anynore so it can steal the focus. The problem is that the page jumps during the find make the history to be updated, and when a links is activated from the history, the view is focused, making the findbar to lose the focus. I think we should not even update the history during search operations and simply add the current page to the history when the search finishes. What do you think?
ah, I see it now, so when the jump is more than two pages you get the entry added to the history. it makes sense. So comment 4 is completely wrong, yey me! Carlos, it makes sense to me to not update the history until the focus goes back to the view.
Ok, I've fixed it by not updating the history while searching.