Implementing form filling and accessibility in the Firefox PDF viewer

https://hacks.mozilla.org/2021/10/implementing-form-filling-and-accessibility-in-the-firefox-pdf-viewer/

by xojoc • 5 years ago

177 78 5 years ago

hacks.mozilla.org

gsliepen• 5 years ago

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.

djbusby• 5 years ago

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

jessaustin• 5 years ago

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...

ocdtrekkie2• 5 years ago

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.

tjoff2• 5 years ago

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 ...

arbitrage• 5 years ago

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?

rudian2• 5 years ago

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.

InitialLastName5• 5 years ago

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.

zinekeller7• 5 years ago

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).

jeroenhd2• 5 years ago

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...

jrochkind1• 5 years ago

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?

sildur• 5 years ago

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".

BitwiseFool• 5 years ago

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

marcellus232• 5 years ago

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

rudian2• 5 years ago

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

Preview.app is king.

michaelmrose• 5 years ago

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?

InitialLastName5• 5 years ago

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?

tpmx3• 5 years ago

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.

zinekeller7• 5 years ago

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?).

motform• 5 years ago

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.

mdiesel• 5 years ago

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.

InitialLastName5• 5 years ago

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!

seanw444• 5 years ago

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

kuschku• 5 years ago

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

sudosysgen• 5 years ago

Okular works.

evmar• 5 years ago

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.)

jd3• 5 years ago

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/

frankjr• 5 years ago

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).

zinekeller7• 5 years ago

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.)

muizelaar3• 5 years ago

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
  --------------------------------------------------------------------------------

fzzzy2• 5 years ago

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.

jfk13• 5 years ago

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.)

zinekeller7• 5 years ago

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.

denton-scratch2• 5 years ago

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

fzzzy2• 5 years ago

heheheheheheh

alacritas0• 5 years ago

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

muizelaar3• 5 years ago

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

SigmundA• 5 years ago

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.

fguerraz• 5 years ago

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...

function_seven• 5 years ago

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"

emilsedgh• 5 years ago

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.

gervwyk2• 5 years ago

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)

gervwyk2• 5 years ago

Sorry I confused pdfJs for jsPdf.

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

rectang• 5 years ago

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.

iapark• 5 years ago

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.

spankalee• 5 years ago

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.

lucideer• 5 years ago

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

gizdan• 5 years ago

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.

saagarjha• 5 years ago

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

c0nsumer2• 5 years ago

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...

muizelaar3• 5 years ago

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

c0nsumer2• 5 years ago

Well, thank you!

xvilka• 5 years ago

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

Stampo00• 5 years ago

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.

jillesvangurp• 5 years ago

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.

denton-scratch2• 5 years ago

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.

Implementing form filling and accessibility in the Firefox PDF viewer

Related Stories