I barely looked at Adobe Reader so not sure about that one, it definitely does not work with this PDF though, likely because it's not compliant in several ways. Besides that I wouldn't be surprised if it supports all the required JS APIs and more, just possibly behind some permission prompts.
It might work in Foxit as I believe it supports some scripting. Most of the other native PDF renderers are more static, as far as I know. In either case, I was most interested in the browser-native engines, as I always thought of them as more "static"/limited.
As for documentation on specific features: to be honest, I just looked at the implementations of PDF.js and PDFium. Both only support a subset of the "standard" API, likely for security reasons. But PDF.js for example allows changing a field's background color (colored pixels!), and PDFium allows modifying their position/bounding box (I tried a high res color display by moving a row vertically as if it's a scanline, but things become quite laggy).
I got the same conclusions. Unless I misunderstood, Pdfium is based on Foxit so that should work. And as both pdf.js and pdfium decided to implement only a thin part of the adobe js sdk, then there are good chances that it works there too.
Original author here. This is indeed a bit confusing.
You are right for the case where Firefox's PDF.js is used (local or remote file in a tab or iframe). The XSS problem however is with web-applications that themselves use PDF.js. In that case, it does not run in a separate or special origin; that is a Firefox thing.
You are also right that the PDF format supports JavaScript, but that is something unrelated to this, and indeed highly sandboxed in all cases.
reply