As this being a Non-Regression issue, changing the status to Untriaged so that the issue would get addressed.

Thank You!

The PDF Viewer extension does not belong in component: Internals>Plugins>PDF

Rob, how does PDF Viewer handle these URLs?

Usually, the extension uses the webRequest API to intercept navigations to:
chrome-extension://.../http://...pdf and redirects it to:
chrome-extension://.../content/web/viewer.html?file=http%3A%2F%2F...pdf

https://github.com/mozilla/pdf.js/blob/75dc2bbd359990ebb1c1484f204acf66c3cb8221/extensions/chromium/extension-router.js#L62-L81

If somehow the tab is loaded before the background page has loaded, then the extension reloads these tabs to ensure that the request is rewritten:
https://github.com/mozilla/pdf.js/blob/75dc2bbd359990ebb1c1484f204acf66c3cb8221/extensions/chromium/extension-router.js#L83-L93

I guess that the tab request is handled before the background page has finished loading.
The fix would be to delay chrome-extension:-loads until the background page has loaded.
(in case of event pages, this requirement is not that strict: it is OK if the event page is still suspended when the tab is loaded, except on the first run (i.e. when "chrome.runtime.onInstalled" is to be scheduled).

Interesting!  As you point out, one solution would definitely be to hold off on committing urls with the extension origin until the extension fully loads.  But that would also be, perhaps, a little inconsistent.  In particular, requests for those URLs would work, but if an extension had a request for example.com, it wouldn't.  What's more, this is really only a problem with a) the initial startup or b) if an extension is killed, because otherwise blocking webRequest is restricted to a persistent background page (where startup wouldn't be a problem).

So I'm not sure that this is worth prioritizing, since it seems relatively edge-case-y, and has a "reasonable" (though certainly not ideal) solution.

As a separate thought, I'm curious: have you tried out using a service worker in the extension to intercept these types of requests?  Would that work better in this scenario?

bug 523634 is about deferring resource loads (e.g. example.com) until extensions that use webRequest have finished loading.

I haven't tried Service Workers for my extension, because it does not offer an advantage over my existing method, while at the same time it breaks extension compatibility with older Chrome versions.