GNOME Bugzilla – Bug 741979
Tab scroll to the end of the document
Last modified: 2016-07-07 20:33:44 UTC
-Open a PDF document that doesn't contain a form. -Focus inside the document view (click in it) -Press <TAB> -Evince scroll to the end. Pondering is this is not caused by the fix for bug 503706 <Shift><TAB> does the opposite: scroll to the beginning.
Evince 3.14.1 on Fedora 21. People on other distribution can reproduce.
Yes, this is caused by the fix for bug 503706.
It is also a noticeable annoyance with evince 3.14.1 in Ubuntu 14.10 every time you touch the tab key. It runs crazily fast (and long) through big documents, and cannot be aborted by further input (click, keyboard).
Created attachment 297410 [details] [review] Fix behaviour of EvView when user presses TAB Please note that this is my seconds contribution (first one is unreviewed), so sorry if I did something wrong. Would be happy to get some feedback :)
Hi, this is very annoying bug, I tested the patch with 3.16.0 and it works flawlessly, also confirmed it doesn't breaks the form fields cycle feature with the following pdf samples. http://foersom.com/net/HowTo/data/OoPdfFormExample.pdf http://www.thewebjockeys.com/TheWebJockeys/Fillable_PDF_Sample_from_TheWebJockeys_vC5.pdf
Still can reproduce with vanilla 3.16.1 on Arch Linux
(In reply to Reverend Homer from comment #6) > Still can reproduce with vanilla 3.16.1 on Arch Linux That's because the bug still not fixed. Patch is still pending...
Review of attachment 297410 [details] [review]: From the fixme, which you are removing and not fixing, it seems that the correct fix is to save in the EvPageCache whether the page has form fields or not. Getting the FormFields should be done EvJob, because using the EvDocument API can be slow, and it will be slow if your document has say 1000 or 2000 pages... So getting the information about the FormFields should be done in a different way.
Review of attachment 297410 [details] [review]: ::: libview/ev-view.c @@ +6819,3 @@ view); } In a more careful reading of EvPageCache, you shouldn't need this method at all. In the page_cache you should have the form_field_mapping available, so basically if form_field is null for a page in the page cache you don't have forms in this page. You could compute, in the cache, if it includes forms, the next page that includes forms. that way you could have a global document_has_form in the cache, and also given a page you could have the link to the next page with forms, so when going forward with the tab you just jump to that page.
Sorry for the delay reviewing this (so annoying bug). As José mentioned using the ev-document API is a bit problematic, it requires mutex locks, and for long documents we could leave the UI blocked for long time. I think that a simpler approach could be to never try to move the focus to a different page if there isn't an element already focused in the current page. For documents not having forms, tab will move the focus in/out the web view, like usual. For documents having forms, if the current page has fields, the first field will be focused, and when reaching the last/first field, moving the focus will try find the next/previous field in a different page. So, this could still happen if a document have forms, and there are pages after the current one not having form fields, but it seems more unlikely to happen. So, I'll try with this approach, that fixes the problem for most of the cases. Let me know if there are still issues.
Ok, I've just pushed a fix to master and gnome-3-16 branches, I hope it helps.
*** Bug 753647 has been marked as a duplicate of this bug. ***
*** Bug 763755 has been marked as a duplicate of this bug. ***