Live data from Hacker News

Implementing form filling and accessibility in the Firefox PDF viewer

hacks.mozilla.org

61–70 of 79 posts

Re: Implementing form filling and accessibility in the Firefox PDF viewer

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

Re: Implementing form filling and accessibility in the Firefox PDF viewer

#62

Earlier quoted context omitted.

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

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

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.

Re: Implementing form filling and accessibility in the Firefox PDF viewer

#63
post #25

Earlier quoted context omitted.

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.

Re: Implementing form filling and accessibility in the Firefox PDF viewer

#64
post #2

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

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

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

Re: Implementing form filling and accessibility in the Firefox PDF viewer

#65

Earlier quoted context omitted.

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

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

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.

Re: Implementing form filling and accessibility in the Firefox PDF viewer

#66

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

> 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

Re: Implementing form filling and accessibility in the Firefox PDF viewer

#68
post #2

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

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

Re: Implementing form filling and accessibility in the Firefox PDF viewer

#69

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

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.

Re: Implementing form filling and accessibility in the Firefox PDF viewer

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

Post reply on HN