I'd have no problem with Mozilla releasing a separate PDF viewer, either as an extension, a standalone application or even a Web site. I also have no problem with Mozilla setting Firefox's default PDF application as a stub which downloads their separate viewer. But it shouldn't be built in to Firefox.
In any case, it is not the job of a Web browser to subvert the user's OS setup.
No, because that means you still do have a PDF viewer, but it's whichever the user has installed, most likely Acrobat, which is vulnerability-ridden.
> But it shouldn't be built in to Firefox.
Why shouldn't it? Browsers aren't limited to HTML. They also support plaintext, SVG, many image formats, XML, and so on. What's wrong with supporting PDF?
I didn't say "having no PDF viewer in Firefox", I said "having no PDF viewer".
> Browsers aren't limited to HTML. They also support plaintext, SVG, many image formats, XML, and so on. What's wrong with supporting PDF?
I would call that feature creep; even so, there are still a few differences:
HTML provides mechanisms for embedding images[0], so trying to support some common formats in the browser is a reasonable approach. A better approach would have the OS handle image formats, eg. like the datatype mechanism in AmigaOS[1].
The example image formats at [0] include single-page, non-interactive PDFs. Supporting such an image format might be reasonable, although I've never seen such a thing used in the wild. That's not what Firefox provides, though. Instead, it provides a whole application embedded in a tab, with a GUI for navigating around documents. The equivalent analogy for images would not the facility to decode the format; it would be the bundling of a whole image browsing GUI like Gwenview[2], which I certainly would object to. As it stands, FF treats a standalone image file as if it were a standalone img element, which is perfectly reasonable. The same goes for plain text, which FF effectively treats as if it were in a pre element. Again, it doesn't provide a special application for navigating text files.
SVG is also specifically mentioned in the HTML spec[3], hence providing browser support for SVG isn't straying too far from providing support for HTML. Again, FF doesn't provide a embedded GUI application for navigating SVGs (unless you count the Web Inspector stuff, which also has no place in the browser and should be either a separate extension or rolled into Firebug).
XML is just a syntax, which browsers need to support if they want to support XHTML[4], in the same way they need to support UTF-8 as a syntax for representing the text in HTML documents. Hence it's completely in-scope.
[0] http://www.w3.org/TR/html5/embedded-content-0.html#the-img-e... [1] http://wiki.amigaos.net/wiki/Datatypes_Library [2] https://userbase.kde.org/Gwenview [3] http://www.w3.org/TR/2010/WD-html5-20100624/the-map-element.... [4] http://www.w3.org/TR/html5/introduction.html#html-vs-xhtml
Ironically it had a vulnerability last week, but that's ONE and that's why it got so much attention. Adobe Reader and similar have had hundreds.
To me, that's the way Firefox should work: a fast, lightweight browser, with a powerful extension system.
I get disappointed when Mozilla add "features" to Firefox, like PDF viewers, Pocket, etc.