Chrome's PDF plugin is closed source, and written in C.
It is very useful, but not free as in FOSS.
We don't even know the details of the Mozilla-Google deal. For all the openness that Google and Mozilla appear to proffer, the agreement between them is a secret.
As a non-profit, we are here to create a public good. It's actually goods, plural, and services too. Firefox and other Mozilla products and services exist to promote the Mozilla mission, not to enrich the Mozilla organization.
Yes. Sustainability is certainly a factor in some of our decision making. Mozilla would be foolish to ignore significant opportunities to increase its mission impact. But revenue for sustainability is not the sole or even the dominant factor in any major product decision at Mozilla.
Plus, there are probably some advantages to having Google 'on side'.
I think this is sufficient to show that they're at least thinking about it.
http://googlesystem.blogspot.com/2010/08/google-chromes-pdf-...
Now start China bitching.
Acrobat is the new Foxit nowadays!
E.g. look at the size of this page: https://www.adobe.com/support/security/
Java has had multiple drive-by exploits discovered in just the past few months, which by definition don't require confirmation.
I was inaccurate, however. Java is almost certainly the cause of most exploits, but I daresay that user inexperience (to put it kindly) is probably the source of most infections. Touchè.
Sandboxing is certainly a good thing, but it's not perfect. Sandboxed code still increases the attack surface. The rationale behind pdf.js is that, because it's almost entirely unprivileged JavaScript, it's unlikely that there's a way to exploit a browser in the presence of pdf.js that wouldn't work in the absence of pdf.js.
How it works today is what matters to users. Tomorrow the native stack will just make use of more hardware features, it will still be faster, and we'll still be having the same conversation that we'be been having with JS ideologues for 10 years now. "Someday ..."
This is what the XML ideologues used to say too. The problem wasn't XML, it was the libraries, or the lack of dedicated XML processing hardware. Then someone realized that if you got rid of the core complexity -- XML -- you could stop layering on piles of additional complexity while trying to work around the root of the problem.
Someday...