Implementing form filling and accessibility in the Firefox PDF viewer | Hacker News Reader

Implementing form filling and accessibility in the Firefox PDF viewer

hacks.mozilla.org

177 pointsxojoc78 comments

PDFJS is fantastic.

But PDFJS folks, how can you do such a subpar job at documentation?

There is really no documentation available on pdfjs. Or a proper changelog. Like in this article they talk about JS execution in pdfjs. And how they have a solution called quickjs. _no_ documentation whatsoever about how to use it.

This has been their documentation for years:

https://mozilla.github.io/pdf.js/api/

Had I created something as complex and magnificent as pdfjs I would've documented _the hell_ out of it.

I get that pdfjs usage in normal web is not their priority and what they care about is the Firefox pdf viewer but I'm sure they would've had a much better contribution rate had they done better api docs.

Shameless plug. I recently wrote an article for Lowdefy (co-founder here) for using pdfMake with Lowdefy to generate pdfs. Works really great and easy, perhaps the next step is to add a pdf render block using pdfJs.

See the article: https://docs.lowdefy.com/generate-pdf-document-from-data

(edit: confused pdfJs for jsPdf)

Sorry I confused pdfJs for jsPdf.

Perhaps the next step is to build a Lowdefy block that uses pdfJs to render pdfs :)

I recently had to implement a custom PDF viewer using PDF.js. It took a loooong time, because PDF.js is so confusing to work with. We went way over what we thought was a conservative time estimate. :(

It's not just a matter of documentation, but API design. Beyond the bare minimum functionality, you'll need bits and pieces of semi-public API.

For example, if you want to use the "text layer" (for selectable text) you'll need a CSS file which is inside the `web/` directory. But what's in `web/` is incomplete and not officially supported.

I wish there were better wrappers for it too. One of the projects I'm still quite proud of that I made as a student was a react wrapper around PDF.js used here https://boardbook.kent.edu/ (though since they no longer seem to be using it I guess it will probably go dead at some point), but the fact there wasn't really a good open source one and as you say the docs were pretty lacking. My favorite discovery was that the performance was much worse unless I registered a particular scroll listener. It's been years now so I only vaguely remember, but I think registering a listener for `wheel` would cause scroll events to be treated as blocking and this made the whole scrolling experience less janky.

This reminds me that I should finish off my <pdf-viewer> event based on PDF.js with the goal of just being able to drop an easily customizable viewer into any page:

https://github.com/justinfagnani/pdf-viewer-element

On the docs front, I couldn't agree more. It's tough to use.

> And how they have a solution called quickjs. _no_ documentation whatsoever about how to use it.

This isn't an excuse for the lack of docs for pdfjs itself, but fwiw quickjs is a 3rd-party project that's documented here https://bellard.org/quickjs/quickjs.html

A while ago I tried parsing my payslips with PDF.js. It took me way too long to figure out the API calls needed. There were a few examples and that's it.

Yeah, it’s a strange choice considering they ask people to not use their viewer unmodified…

Why is it that, a ~decade since MacOS started including forms and markups in their default PDF app (Preview) there still isn't a sane PDF editor for Windows? Chrome and Firefox's PDF viewers don't have editing, Edge has editing and forms but bonkers window management (sometimes PDFs open with Edge but not in an Edge window). Adobe Reader DC still tries to ship with malware, and is license-restricted. What gives?

Apple did it because they were the underdog 15-20 years ago. Microsoft doesn't give a shit. There's no realistic market opportunity for a small third party to get a sizeable amount of revenue either, with Adobe looming.

I kinda miss the early 90s when we actually had competing software "houses" with some financial muscle.

Wrong answer, at least for a time. Microsoft was actually sued by Adobe over the PDF implementation with Office 2007 (before it was standardised in ISO, that was circa 2008-9 if I remember correctly). That's also the reason that XPS (the weird Microsoft format, not Dell laptops) exists.

Nowadays though, I don't really know since Microsoft has successfully overturned that case (probably because of Adobe being Adobe?).

So, not really the wrong answer for the past 12 years or so, then.

The number of years depends on when the various patents expire. Does anyone know?

preview.app has been around since NextSTEP, which used display postscript for its windowing engine. Having a first-class pdf reader falls out pretty naturally.

Sure. Spending money on implementing okayish PDF forms support.. I'm going to out on a limb here and say that it wasn't done out a position of strength.

wild guess here -- MacOS had given way to MacOSX, but commercial printing and publication workflows had not. Windows via market mechanisms (plus assorted dirty tricks), had a lot of installed desktops by that time in the print world, with a much smaller set of the artsy people and some others still championing Macs. When MacOSX got stable after the first few releases, the NeXTstep postscript handlers were there, and Apple wanted to compete to get users to buy new Macintosh hardware for print. Anything and everything to attract print people was definitely included.

Forms were appealing to some businesses and I dont have insights on that part of it, other than noting that odd media formats and bolt-on web'by things were being added to PDF at the time, and as for common forms solutions, apparently fifteen years later its still not settled.

I use PDF XChange Editor, and convinced my company it was worth it to pay for it (which it is). Aside from editing capabilities and everything else you'd want, it opens and searches large files far quicker than anything else I tried.

On mobile, I use MuPDF but its limited on features and I use because it's quick.

I've always been sketched out by PDF XChange Editor (not sure if it's the name, the developer's name, or the model) but it's interesting to hear that it's legit. Will have a look!

Yeah, the website also looks very offbrand, but the product is really more than just solid.

Granted, MuPDF is intended to not have a ton of features. Just the essentials.

I just use KDE Okular on windows, it’s available in the microsoft store.

Okular works.

My recollection is that you need a license to PDF patents from Adobe to implement those things, and Apple is somehow grandfathered themselves into those licenses via NeXT.

(But upon writing that I'm not sure where I got that impression from, and I can't find a citation for it right now, so treat the claim with skepticism.)

ignoring the "thoughts on flash"[0] letter, the apple <=> adobe relationship goes back to at least the apple LaserWriter[1], so that would definitely make sense

the Quartz compositor itself has "use[d] pdf internally"[2][3] ever since the initial launch of Mac OS X

> By the time OS X came out, these were less the kind of features that "the next great personal computer operating system" should have, and more the kind that they all had. What was new included how Quartz, the engine for OS X's "killer graphics," was based on PDF.

> "What does that mean?" asked Jobs. "You know when you go to the web and you see PDF documents? Well, that technology is now at the core of Mac OS X's graphics. So you can image PDFs instantly. So now all applications get this for free."

> It's how, to this day, every Mac app can produce a PDF document without needing a third-party app.[4]

[0]: https://web.archive.org/web/20100531072734/http://www.apple....

[1]: https://en.wikipedia.org/wiki/LaserWriter#Apple's_developmen...

[2]: https://www.youtube.com/watch?v=Ko4V3G4NqII / https://www.youtube.com/watch?v=6-fkYFV7rOY

[3]: https://en.wikipedia.org/wiki/Quartz_(graphics_layer)#Use_of...

[4]: https://appleinsider.com/articles/21/03/24/apple-launched-it...

https://pspdfkit.com/blog/2020/apple-and-pdf-history/

To this day, I do not understand why it is practically impossible to simply rotate a PDF and save it in its rotated form without downloading some additional PDF application.

Edit: On Windows. I envy Preview in MacOS

Might want to specify the platform. on macOS that's like 2 clicks in Preview.app.

It’s a single key shortcut. The document is then auto saved.

Preview.app is king.

Is it actually rotated or does it just remember that that document is supposed to be rotated? In other words if you emailed it to me would it still be rotated when I opened it?

Actual PDF rotate.

In other news, that's precisely why I'm weary to open PDFs in (edit: recent versions of) macOS because it autosaves, and I need to have a bit-perfect copy of said PDF. I mean, I open it in Firefox or Chrome, and this is just a problem that is specific to my circumstance, but it still bugs me.

I think there’s an option in System Preferences to disable auto saving

That's if I do own my own Mac, but this is in situations like if I'm stuck in the marketing division and needed to view a file immediately.

You may need to save it, but you can rotate just one page in Preview and keep the rest in its original position. I also like that you can click the title in Preview, edit it, change the location, without having to close the document.

I'm glad PDF.js' development continues. I completely missed that they have abandoned the plan to move to PDFium (https://wiki.mozilla.org/Mortar_Project).

Mozilla developers at the time actually have other plans with the Pepper plugin support: Adobe Flash (since that Chrome's Pepper Plugin API (PPAPI) is actually miles better and secure than the Netscape [-era - ed.] Plugin API or NPAPI).

They abandoned Mortar when Adobe have announced that it will retire Flash.

(Also, PDF.js is now a misnomer: it now mainly uses WebAssembly.)

It doesn't.

  --------------------------------------------------------------------------------
   Language             Files        Lines        Blank      Comment         Code
  --------------------------------------------------------------------------------
   JavaScript             355       144428        13069        16759       114600
   JSON                    12        24385            2            0        24383
   CSS                     12         3302          407          183         2712
   HTML                    32         1638          176          230         1232
   Markdown                19          733          221            0          512
   TypeScript               1           20            4            2           14
   CoffeeScript             1           15            2            0           13
   YAML                     1            4            0            1            3
  --------------------------------------------------------------------------------
   Total                  433       174525        13881        17175       143469
  --------------------------------------------------------------------------------

I'm referring to the one built-into Firefox, not the HTML version. Even comparing the HTML one, this is misleading: the PDF.js compilation step means that there are WebAssembly code written nominally in JavaScript, namely those that handles font rendering and complex graphics (before pushing into the canvas, which by necessity is done in JS).

There is no wasm in the version built-into Firefox.

I think it's funny that someone added 1 CoffeeScript file to the codebase and didn't write a single comment about it.

PDF Forms are tricky. Though I would prefer if more attention given to the native PDF libraries like poppler[1] that drive Okular, Evince, Zathura, and many other PDF viewers. There are long-standing bugs[2] with PDF Forms support, especially with non-English languages[3][4][5].

[1] https://poppler.freedesktop.org/

[2] https://gitlab.freedesktop.org/poppler/poppler/-/issues?labe...

[3] https://gitlab.freedesktop.org/poppler/poppler/-/issues/463

[4] https://gitlab.freedesktop.org/poppler/poppler/-/issues/230

[5] https://gitlab.freedesktop.org/poppler/poppler/-/issues/364

> Thanks to our Telemetry, we discovered that many forms contain and use embedded JavaScript code (yes, that’s a thing!).

There are two disturbing things in that sentence. At least the JavaScript I can see a reason for, it can check whether your input is correct and maybe autofill or things like that, and should of course be sandboxed. The telemetry part is more scary.

Scary and also helpful. Over reaching telemetry bad. But pragmatic, anonymous, usage metrics? Maybe worked this time.

It would be possible to implement telemetry that would answer these questions in mostly unobjectionable fashion, but without more information one can see how this could be described as "scary". I certainly hope that forms aren't just being sent back home to Mozilla as-is. However, a monthly ping with statistics like "out of between 50 and 200 documents, between 10 and 50 of them used javascript" wouldn't harm anything. They could even add a random error to the statistics...

I often do not have a problem with the information telemetry collects: I take issue with the entitlement to it a new breed of awful app developers have. They think they have the right to use my device for information collection without my permission.

If Firefox occasionally showed me a report on some metrics it collected and asked me if I was okay sending it to Mozilla, I'd probably be fine with it. However, the choice to take it without my consent will always be opposed.

Do they do that? It's been a long time since I installed Firefox, but as far as I can tell there are very visible settings for controlling the telemetry that they collect.

There are settings, however, they are enabled by default to silently send telemetry, and they also implement new ways of collecting telemetry, with new settings to opt out of it, on an "every few months" basis. So it's a constant battle of monitoring what behavior they're up to and turning it off.

It would be possible to figure this out without any sort of telemetry at all.

It really feels like a forced way to try and shoe-horn something good to say about telemetry when it is something everyone that deals with PDFs have known since forever.

And if that is the best they have to show for it ...

How would you figure this out without telemetry?

A Web crawl could tell you how many PDF documents on the Web use forms, but it won't tell you often your users encounter those documents --- many documents aren't on the public Web, and some documents will be encountered far more often than others.

> How would you figure this out without telemetry?

the way the world has done it forever... a survey?

it is concerning. if Firefox is doing it, they are all doing it. i am not going to be opening PDFs in browsers.

this is ridiculous.

A survey for this is going to be useless for getting unbiased data.

A survey would be heavily biased. Telemetry will have much less bias (there is still some since people who disable telemetry have their usage ignored)

With better data you can make improvements that help more actual users instead of just focusing on what vocal minorities think.

The vast majority of questions like that are quite obvious.

Now what you might miss is that in some country where special circumstances led to an unusual high use of a certain feature.

But this is not that case.

More importantly, even with telemetry. Is the JavaScript adding something or is it solely used for tracking? Is it appreciated by the users?

Maybe 80% of input validation is so broken that they only serve to block legitimate input and waste cpu-cycles.

More than telemetry you need common sense. It is not apparent how the telemetry influenced this in any way.

What I find disturbing is that you are complaining about the included javascript in forms at this late a date. Where have you been for like the last fifteen years?

Fifteen years is a long time. I’m sure some HN users weren’t even born yet.

Not everyone needs to care about everything all the time. I would complain about JS in PDF too, but I don’t have a voice anyway.

> The telemetry part is more scary.

There's a nice big section in the Firefox settings called "Firefox Data Collection and Use" that has some fairly fine-grained options for what data you feed back to Firefox. I have all of mine unchecked, but I could imagine that if I were more community-minded, or if I were interested in actively contributing to FF's development day-to-day (for example running on nightly builds) I would activate those.

FWIW, I do explicitly allow telemetry for the applications I buy licenses for and use for my work; it's in my best interest for those programs to be improved as efficiently as possible (and to have my use patterns be part of the corpus used to prioritize those improvements), and it makes it easier for me to report issues.

Also, unless you dismiss it, there's a clear button to read to read their privacy policy and set telemetry (unless you're using the nightly-weekly builds, in this case they state in no ambiguous terms that you cannot disable it).

> that has some fairly fine-grained options for what data you feed back to Firefox

I looked into these settings but I can only find 4 checkboxes. Which of the four checkboxes would this telemetry fall under? Is this a study, the result of crash report logging, or is it "data about your interactions with Firefox [..] (such as number of open tabs and windows; number of webpages visited; number and type of installed Firefox Add-ons; and session length) and Firefox features offered by Mozilla or our partners (such as interaction with Firefox search features and search partner referrals)"

I know Firefox collects some technical tracking, but there is no up to date overview of what tracking is actually done. Is there a list of parameters tracked like Microsoft published [1] after the outcry about their terrible tracking? The privacy policy is vague and the documentation for developers [2] contains phrases such as "opaque prio-specific payload. Like { a: <base64 string>, b: <base64 string> }" which isn't exactly useful.

[1]: https://docs.microsoft.com/en-us/windows/privacy/required-wi...

[2]: https://firefox-source-docs.mozilla.org/toolkit/components/t...

Disclosure: I don't have any relation to Mozilla (so some of this could be wrong), and about half of it I discovered after reading this comment. I do run Firefox Nightly, and follow Firefox development somewhat.

I don't see the same screen you do (perhaps something to do with telemetry being force-enabled in nightly?) so this is based off of what you wrote:

> Is this a study...

Studies are generally minor tweaks in user configuration sent to a subset of users (often nightly), and then telemetry between control and experiment groups is compared. You can see what studies you have been in at about:studies. For example, some of mine include setting the user-agent to Firefox 100 (to test a 3-digit number), enabling fission (and a number of things with process counts and whatnot), enabling HTTP/3, and (I kid not) "Changing a pref that does nothing - to check enrollment and unenrollment reliability." A lot of the time if you inspect element the source has a bug number you can look at (which really ought to be a built-in feature).

> The result of crash logging

You can see this in about:crashes; this is when the browser or a process (eg. GPU) crashes.

> Data about your interactions with Firefox

Probably, this seems like the most broad and undefined one

> Number and type of installed addons

Seems self-explanatory

> Firefox features offered by Mozilla or our partners

Not really sure about this one, presumably it relates more to things that have to do with third-parties or them making money

> Overview of tracking

See about:telemetry. That has links to a number of other pages I didn't realize existed before today, but which seem to have a pretty comprehensive public overview.

The quote is from Mozilla's own page explaining telemetry, not from the settings screen. The settings are much shorter.

about:telemetry didn't work on my phone (although the screenshots and videos I could find on it seem to indicate that it's just names and raw values, not human-readable descriptions), but it did contain a link to https://probes.telemetry.mozilla.org/ and the newer https://dictionary.telemetry.mozilla.org/ that seem to contain an overview of telemetry data collected.

I don't see anything on there about PDFs and Javascript, so I'm guessing there's another telemetry endpoint out there that I'm not seeing. Maybe the PDF renderer has a separate telemetry system, I don't know. Seeing the amount of (IMO useless) data Mozilla collects, I'll be opting out from telemetry from now on anyway.

> FWIW, I do explicitly allow telemetry for the applications I buy licenses for and use for my work; it's in my best interest for those programs to be improved as efficiently as possible (and to have my use patterns be part of the corpus used to prioritize those improvements)

Makes sense. How do you see Firefox as different; you don't pay for it, but, if you use it, you presumably still might want it to be improved efficiently and based on your use patterns. But no?

A) The data that flows through my browser is private to me, and I have no assurances that Firefox will respect it. The tools I use for work have a license that openly respects IP (without which they wouldn't be in business) and I'm am comfortable that their business model relies more on keeping me as a customer than selling the (limited) IP that flows through their tools.

B) The tools I use are force multipliers for me, that differentiate from their competition through the improvements they make (thus making me far more productive than I otherwise would be). I use Firefox, but there isn't a huge amount to distinguish it from other browsers, and it's not clear to me that improvements in browsers over the last 10 years (beyond security) have added enough value to my life to need my data.

C) For the tools I'm using, I am one of a relatively small number (tens of thousands) of users, I am occasionally in direct contact with their staff (again, I pay for this support, among other things); my contribution of telemetry data to them is making a substantial contribution. For Firefox, with its install base in the hundreds of millions, my individual contribution is meaningless.

Not only that. If they wanted to add form support they should have read the specs, instead of blindly relying on their (very questionable) telemetry.

The fact they had to find via telemetry something that every developer who had interacted with a PDF with forms knew (that they have JS) is very worrying.

I'm expecting a long long list of bug reports when they start finding the mountains of corner cases not shown by their "telemetry".

I wish the Firefox PDF viewer performed a little better...

Lately as I've been working on mapping projects and want to view large PDFs I've found many which need to be saved and opened in Preview.app instead of the browser.

This is a great example of a map which views horribly in Firefox (try zooming in) but works great in Preview.app: https://www.bia.gov/sites/bia.gov/files/assets/public/webtea...

I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1736108 for that case.

Well, thank you!

I have a learned aversion to PDF features such as forms. It's partly because HTML already has pretty good forms; and partly because of the long history of gross PDF security failures by Adobe.

I think a PDF viewer (I prefer "reader", because that's what Adobe called their free product) is for viewing PDFs. The point of PDF, to my mind, was that you got a much higher level of control of typography and design than you could get with HTML. So designers and marketers liked it. I have never bought into interactive PDFs.

Remember when Mozilla management promised that they were going to kill pdf.js (why?) and replace it with the chrome pdf viewer, then wasted a few years not pulling it off? Good times.

Sometimes plans don't work out (and/or circumstances change), and changing them is the sensible thing to do.

(I don't know details of this specific case, and whether/why the plans and decisions made sense at any given time.)

I'll copy out this comment of mine in response to an analogous question:

> Mozilla developers at the time actually have other plans with the Pepper plugin support: Adobe Flash (since that Chrome's Pepper Plugin API (PPAPI) is actually miles better and secure than the Netscape [-era - ed.] Plugin API or NPAPI). They abandoned Mortar (the name of the project) when Adobe have announced that it will retire Flash.

Mozilla management have never been up to the job; clearly their pay needs to grow drastically, to attract better talent. /s

heheheheheheh

The new PDF form rendering is working great for me. Thank you, Firefox! I don't love PDF files, but it's more convenient for me to deal with them in my favorite browser.

It's impressive how slowly progress has been made on the firefox pdf viewer. They can't print out pages which aren't blurry from the viewer even though they've had 8 years notice: https://bugzilla.mozilla.org/show_bug.cgi?id=811002

That bug is closed. What PDF and platform do you see blurriness on?

https://github.com/mozilla/pdf.js/issues/2750

It's because pdf.js does not print vector and instead is just printing canvas bitmaps. If they ever get the SVG backend working its will finally have good print quality without trying to get OOM doing measly 300 dpi canvas.

It seems to me that with WASM, it's easier than ever to have good cross platform and performant implementations for dealing with pdf and many other file formats in a sane way.

There is a lot of open source software out there that probably already can be compiled to run in a browser with WASM.

I wonder when Mozilla is going to start to include ads in their pdf renderer.

I mean it wouldn't really be "ads", more like suggested extra pages provided by trusted partners...

They could really add value by using AI to detect certain PDF forms. If the form you're filling appears to be a tax return, then a Helpful Message from a Trusted Partner would appear ("TurboTax users average $300 larger refunds").

Residential mortgage application? "Shop Rates and Save"

Reply on news.ycombinator.com