Created attachment 138373 [details] [review] Patch to add support for next actions Next actions are action dictionaries or an array of action dictonaries. "Next" is an entry in the general action dictionary. These actions are supposed to be performed after each other. So that a single button press can for example both trigger a hide action and a JavaScript action. This is generic for all action dictonaries. (Adobe PDF Reference 1.7 Section 8.5.1 page 647). I've noticed the necessity for this while playing with an example in to support Hide Actions ( https://phabricator.kde.org/T8274 ) as Adobe Acrobat DC would only allow to create a hide action for a single target and otherwise use next actions to hide multiple fields at once. This patch is part of a work on Okular ( https://phabricator.kde.org/T8278 ). The corresponding Okular change extends an autotest to test this feature. As an example document the "visibilitytest.pdf" from https://phabricator.kde.org/T8274 can be used.
This is one of those cases where malformed PDF can loop poppler forever creating a loop in the Next array by using an Array of references to dicts, i.e. something like (non valid PDF syntax for sure ) 1 0 obj Dict Link stuff /Next [ 1 0 R ] stuff This would end up in a parsing loop, and it's worse the loop can be introduced at any time 1 0 obj Dict Link stuff /Next [ 2 0 R ] stuff 2 0 obj Dict Link stuff /Next [ 1 0 R ] stuff So what we need to do is something similar to what we do in other cases an std::set<int> seen that we pass to the parseAction, then when parsing the array call getNF, if it's a ref check/add it against seen, if it's a dict, just carry on and if it's a ref and not seen before fetch it and carry on too. If you grep for std::set you'll find some cases around the code that deal with that. I wish we had a generic way to do it since it's kind of cumbersome to do every time we're parsing a tree of objects of the same type :/
Created attachment 138704 [details] [review] Patch to add support for next actions - Update 1 Yes. I thought "well we are in PDF Form / JavaScript Land" anyway but you are right, of course, segfaulting with an endless memory allocation is never nice :-P I've updated the patch accordingly and update the visibilitytest.pdf document that I use in the okular unittest to contain such a loop. This allowed me to reproduce a segmentation fault without this change. Could you extend / add the visibilitytest.pdf to also contain an array of next actions that show such a loop? I was unable to construct one. I could replace a ref to a next action but when I tried to change it to an array I only produced invalid pdfs. So the second codepath relating to the Arrays is untested :-/
pushed (with some improvements)
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.