From what I understand this wasn't so much about bundling everything into the web browser. It was more about the handling of links to PDF files that are served with `content-disposition:attachment` to get the browser to open the "choose an app to open this file" system dialog. Without Firefox being registered with the system as an app that could open PDF files, users wouldn't be given the option to open it with Firefox (often they'd be prompted to open it using Edge). That was annoying people.

Regarding your security concern, Firefox's PDF viewer is PDF.js. Parsing PDF files in a JS sandbox and rendering it to an HTML <canvas> in a sandboxed process should be more secure than rendering it using an unsandboxed app that parses/renders using system APIs.

> Regarding your security concern, Firefox's PDF viewer is PDF.js. Parsing PDF files in a JS sandbox and rendering it to an HTML <canvas> in a sandboxed process should be more secure than rendering it using an unsandboxed app that parses/renders using system APIs.

Almost definitely. You can go to https://www.exploit-db.com/ and search for PDF and see many application exploits for PDF viewers, and that includes for linux (and not just commercial applications, Poppler is on there as well, though more than just a few years back).

PDFs have shown that they are a fertile ground for exploit, so running them though a sandboxed VM is a very good way to limit that problem to some degree.

> Without Firefox being registered with the system as an app that could open PDF files, users wouldn't be given the option to open it with Firefox (often they'd be prompted to open it using Edge). That was annoying people.

Huh that's cool that it's fixed now. It annoyed me so much that I installed an extension for it: https://addons.mozilla.org/de/firefox/addon/open-in-browser/

That's great news. I get fed up of random PDFs littering my Downloads folder.

I'd actually consider browser pdf viewers safer than a standalone native app. Firefox uses pdfjs, a pure javascript pdf implementation running inside a battle-tested browser javascript sandbox. No unsafe native pdf code with countless holes.

They have long adopted Chrome's C++ one, given performance complaints.

No it does not, Firefox still uses PDF.js. This is extremely easy to verify by just right clicking and hitting "Inspect Element" on any PDF opened in Firefox (and also you can then just load PDF.js into Chrome on a page, load a pdf into that, and verify the same behavior.)

I stand corrected then.

Did they? I thought they explicitly rejected it.

https://bugzilla.mozilla.org/show_bug.cgi?id=1049218

Incorrect, that was abandoned and pdf.js is very-much what's being used.

Honestly, I really miss Edge's EPUB support. Like really miss it. There's a lot of things I think browsers should not do. WebUSB? WebMIDI? Burn these things with fire. Do not connect the web browser to hardware.

Web browsers are supposed to actually be document viewers. HTML is a document format. I am 100% on-board with web browsers also reading PDFs and EPUBs.

I know Mozilla is hurting for manpower right now, but I'd drop dead with excitement if EPUB support came to Firefox.

Fortunately Sumatra (on Windows) opens pdf, epub and mobi files: https://www.sumatrapdfreader.org/free-pdf-reader.html

I switched to it a while back and haven't looked back since. It's open source too.

> Web browsers are supposed to actually be document viewers.

That ship sailed long ago. For better or worse, web browsers are application platforms now.

Not really sure about WebUSB but WebMIDI is pretty harmless, surely?

The browser probably won't be good enough to replace Ableton (or similar) for a while but it is the primary medium for a lot of digital (interactive) artwork - for projects that use sound it's nice to plug a MIDI device straight into the browser.

As long as VSTs are native-only (which based on the low-latency nature of audio processing would probably never see a cloud implementation,) web-based DAWs will never replace locally-run ones. Most music studios airgap their systems anyway.

You could probably get alright performance running in the browser using webassembly. No idea if anyone's working on anything like that.

I'm curious too. From a quick search, I found WebDSP, "A client-side DSP library utilizing the power of WebAssembly".

https://github.com/shamadee/web-dsp

> WebDSP is a collection of highly performant algorithms, which are designed to be building blocks for web applications that aim to operate on media data.

> The methods are written in C++ and compiled to WASM, and exposed as simple vanilla Javascript functions developers can run on the client side.

..On further reading, they have functions for video and image processing, but not audio as far as I can tell.

---

There's Glissando, "A web-based digital audio workstation using the web platform APIs (Web Audio, Web MIDI) and WebAssembly".

https://github.com/glissando-daw/glissando-app

They mention "VST support", but I cannot imagine how that's possible from the web.

It can be used for fingerprinting. And most people who care enough to own dedicated MIDI devices also care enough to own dedicated MIDI software.

How far do you go with that? Should web browsers render .docx?

I mean, sure? XML-based document formats aren't really foreign to web browsers anyways, and it'd probably be a safer way to view third party documents than Word...

And just like that, we'll reinvent OLE eventually, but with HTML5 and JavaScript.

Yeah, that would be awesome.

on macos, you can just use the built-in preview app. it's similarly not as advanced as acrobat, but a little better than firefox's pdf.js.

i also like opening pdf's in a separate app, as they're usually not part of the main "stream of thought" of the page from whence it came.

I suppose it's easier for a browser vendor to build this into their existing program than to create an entirely new one. Your sentiment is understandable to me, (my) PDF viewing is disconnected enough from web browsing to warrant being split off into a separate program. But PDF is probably an expected feature from a browser for many people.

PDF as a native browser feature started IIRC with Chrome — until then, everyone had to use a plugin. I’ve always thought the reason Chrome built in a PDF reader was that Adobe Reader was really slow to start and brought the browsing experience to a jarring halt.

People would even put in “warning: pdf” text when linking to PDFs because of how Adobe Reader slowed people down.

I thought PDF.js was the first implementation. Firefox added it in 2012.

Chrome’s PDF viewer launched in Dec 2010[1] with v8.0.552.

The release notes do note that a benefit of the built-in viewer is that it’s sandboxed. That’s fair enough, I guess — the Chrome team had a bee in their bonnet about plugins going all the way back to the Chrome launch comic[2].

Interestingly the Chrome team were using svn back then — that’s how long it’s been :-)

[1] https://chromereleases.googleblog.com/2010/12/stable-beta-ch...

[2] https://www.google.com/googlebooks/chrome/big_28.html

This is my recollection, too. Firefox was first, with pdf.js

Zathura is fantastic.

Give Sumatra a chance. At least under Windows. It requires a bit of love in terms of changing default color (e.g. single value in config file, from bright yellow to something toned down), but it super fast, lightweight and open wide range of formats (pdf, epub, mobi, djvu).

I (not OP) believe I have. It’s nice, but Zathura can use the same engine (MuPDF, which is responsible for the speed and format support, although Zathura also supports Poppler, which Sumatra has removed support for), and is beautifully vi-like. And what advantages does Sumatra have over pure MuPDF? DRM?

If I am not mistaken Sumatra is windows-only (zathura is cross platform) and enforces DRM (you can't copy from documents which disallow it). It is objectively an inferior option.

This, but at least in my Debian oldstable based distro, it requires Poppler, which the currently highest sibling of your post has pointed out has had vulnerabilities at least in the distant past (Edit: ~7+ years ago). (Edit the second: upstream also supports mupdf https://pwmt.org/projects/zathura/plugins/, but that’s had exploits as recently as 2017 on https://www.exploit-db.com/.)

global warming took a massive hit due to corona. If there ever was a time to support it then that is now and what better tool for it than a JavaScript based PDF viewer. That thing routinely drained my EEE PC empty when it first came out, can we get an environmental seal for software so that we have an official logo to shame JavaScript developers with?