A few years ago, we used a different method to replace the document with HTML for the viewer. The disadvantage of this method is that it could take a few seconds in the worst case and you would briefly see a flash of gibberish (and it doesn't work for iframes either). Then I submitted a patch to Chromium so that we could get a better method to show the viewer more quickly, by intercepting the PDF request and redirecting it to the viewer (#3751).

I'm aware of the usability issue with the viewer, and I'm investigating options to resolve this. E.g. the development of a new Chrome extension API that allows extensions to modify the displayed URL (https://groups.google.com/a/chromium.org/d/msg/apps-dev/95IVTx4AiFU/gax8vKlbTD4J).

Until that feature is available, the easiest way to get a URL for the PDF is to click on the PDF.js icon in the omnibox and select the URL:

Welp. Now the PDF icon is not even shown in the omnibox. Chromium team have lost their minds..

Brief summary of #9646, which was closed as duplicate of this but takes a slightly different angle.

Using a chrome-extension:// URL prevents any other extension from modifying or accessing the page content at all. This breaks extensions such as Vimium, which rely upon being able to inject elements and event handlers into the page. Changing the displayed URL presumably wouldn't grant those third-party extensions access to the page again, so I imagine the only solution would be to go back on the approach introduced in #3751, and just start modifying the page's HTML again.

This chrome-extension:// prefix really makes it more awkward to copy the URL to the clipboard, e.g. for sharing or for storing externally in a personal knowledge base. I need to do this often enough that for me unfortunately it's sufficient reason to disable the extension. But if this is not easy to fix, perhaps a workaround might be to offer an icon and keyboard shortcut for copying the original URL to the clipboard.

I'm considering to introduce an option to allow the user to choose between the current behavior (URL replaced) and the requested feature (URL preserved).

Chrome does still not have first-class support for allowing extensions to handle specific MIME types.

My implementation plan is as follows:

• This requires the Chrome browser to include PDFium (which is the default) as the default PDF handler. The browser will then switch to a document with a PDF embed as soon as possible.
• Convert "Content-Disposition:attachment" to inline to allow downloads to be displayed inline, as before.
• Use content scripts to detect the PDF document, and replace the current DOM with shadow DOM where the content is rendered, in an iframe.

@Rob--W is this still planned?

@Rob--W is this still planned?

I forgot about this one. I've scheduled a reminder for myself to take another look in a month.