Allows the PDF engine return the page index it is scrolling to
Chromium/PDFium behave differently from IE/Acrobat, when it
comes to the way some Javascript that scroll to a given
page index is handled.
For instance, lets assume a PDF file is showing its page
'0' and the following JS runs:
this.pageNum = 1;
app.alert(this.pageNum);
The output of the alert in IE/Acrobat is '1', whereas it is
'0' in Chromium/PDFium.
This happens because of the asynchronous way Chromium's PDF
plugin handles the "scroll to page X" request.
Also, a similar behavior difference is seen on other
Acrobat JS APIs, including Document::gotoNamedDest, where
the same code path is taken to scroll to a given page index.
CL adds an "optional" class member variable that
caches the page index the PDF is going to be scrolled
to, and allows the PDF plugin to return the target page
index even before the it has finished handling the scroll
request.
BUG=pdfium:492
Review-Url: https://codereview.chromium.org/2271263002
Cr-Commit-Position: refs/heads/master@{#414921}
2 files changed
