Plans for MV3?

[azhx]

@Rob--W
Hi, I asked this question in the matrix channel and got told to put an issue here and ping you.

I just read your post about the Firefox add-on ecosystem here https://blog.mozilla.org/addons/2022/05/18/manifest-v3-in-firefox-recap-next-steps/

I understand that firefox add-ons will not be forced to migrate to service workers, but are there plans for migrating pdf.js to Chrome's MV3 requirements which do require this? Since the chrome web store has already stopped accepting mv2 extensions, it won't be possible to use pdf.js in any future chrome extensions without this effort, and it seems like by June 2023 pdf.js will simply stop working on chrome.

I wasn't able to find info about any of these plans online.

[Rob--W]

it won't be possible to use pdf.js in any future chrome extensions without this effort, and it seems like by June 2023 pdf.js will simply stop working on chrome.

PDF.js (the HTML+JS+CSS based) viewer still works. What's breaking is the extension-specific part that hooks up the PDF requests with the extension itself.

I have sketched the necessary (unimplemented) functionality in Chrome at https://bugs.chromium.org/p/chromium/issues/detail?id=1141166#c18

With the current extension APIs, there is no reasonable way to implement a MIME-type-based PDF viewer in Chrome.

A poor alternative is to intercept requests with the .pdf extension, but that will miss many actual PDF requests.

[exsesx]

This is an unfortunate turn of events. I like pdf.js on Chromium. It's also way better than the native Chrome PDF viewer.

I hope everything will be sorted out and pdf.js will continue working.

[cambraca]

I have sketched the necessary (unimplemented) functionality in Chrome at https://bugs.chromium.org/p/chromium/issues/detail?id=1141166#c18

It looks like these issues are being addressed (as well as the June 2023 deadline moved .. indefinitely?): https://bugs.chromium.org/p/chromium/issues/detail?id=1141166#c25

[Rob--W]

The necessary API to replace webRequest has landed in Chrome 128 (commit), which is currently on Beta and scheduled for release on August 20th.

There are some relatively trivial changes in migration to MV3 (e.g. page_action -> action). Some are more complicated, and listed below:

• Migrate background page to service worker.
• Migrate webRequest.onHeadersReceived based redirects to declarativeNetRequest (pdfHandler.js, available in Chrome 128+)
• Migrate extension-router.js that masks the actual extension URL with a prettier URL, from webRequest to service worker "fetch" event.
• Migrate file_browser_handler (pdfHandler-vcros.js) to file_handlers (https://developer.chrome.com/docs/extensions/how-to/web-platform/file-handling-chromeos)

Before migrating I am also going to delete some obsolete code / work-arounds that are no longer needed. Since header-based declarativeNetRequest redirects is relatively new, I am also considering to look into a fallback that does not require header-based redirect support, which may potentially have "nice" URLs such as seen in an earlier version of the Chrome extension (and also visible in the screenshot in the Chrome Web Store).

The extensions currently specifies a custom CSP to permit unsafe-eval. As this is not possible in MV3, I'm going to remove that from the first iteration. I'm considering to restore it in the future, if the viewer component can feasibly be moved in a sandboxed page. The privileged part of the extension would then have to be loaded from e.g. a privileged extension frame, and be responsible for handling the networking logic and such.

[shivaprsd]

@Rob--W A question and a suggestion:

• Some MV3 extensions on CWS (including mine) based on PDF.js use a content script to detect PDFs (because unlike Firefox, Chrome allows content scripts in their viewer) and then redirect to the PDF.js viewer; basically something like this:

  /* content-script.js */
  if (document.contentType.includes("application/pdf")) {
    ...
    location.replace(viewerUrl);
  }

  This way we let Chrome handle the MIME type. What are the advantages of using the response-header based redirect method over this?
• With the migration, can you also consider renaming the extension to reflect that it is the official one? There are many copycat PDF.js embeds on CWS (with quite a user base!) with very similar names.

[Rob--W]

@Rob--W A question and a suggestion:

• Some MV3 extensions on CWS (including mine) based on PDF.js use a content script to detect PDFs (...) and then redirect to the PDF.js viewer; (...)
  This way we let Chrome handle the MIME type. What are the advantages of using the response-header based redirect method over this?

The original reason for the use of webRequest is that when I developed the PDF viewer extension, that there is not always a built-in PDF viewer in the browser. That would prevent a content script based detection mechanism from working.

The extension already has a content script-based rendering mechanism and will still do something similar as a fallback, probably with an option for users who prefer the UX of the fallback.

• With the migration, can you also consider renaming the extension to reflect that it is the official one? There are many copycat PDF.js embeds on CWS (with quite a user base!) with very similar names.

Once migrated to MV3, the extension becomes eligible again for the Features badge that it had before. I am not planning to rename the extension, since its current name is sufficiently clear and no amount of rebranding will fully avoid confusion with copy cats. Copy cats are a problem of the Chrome Web Store, not of the extension.

[shivaprsd]

... that there is not always a built-in PDF viewer in the browser. That would prevent a content script based detection mechanism from working.

But now can't we safely assume that all versions of chorme(ium) that PDF.js now supports, and also the versions the MV3 variant will be available for, will have a built-in PDF viewer?

Copy cats are a problem of the Chrome Web Store, not of the extension.

I agree, but this is a default problem of all the popular softwares in all kind of app stores, and they do take some measures to highlight themselves from the rest. If not a rename, official branding from Mozilla could IMHO help in this regard.

[qwer1304]

@Rob--W Hello! As you probably know as of version 130.0.6670.0 (Official Build) canary (64-bit) (cohort: Clang-64) pdf.js (and other extensions) is disabled because it's non-MV3. It's still possible to revive it for a couple of days/weeks or use a Chrome policy hack to extend this until June 2025. Soon this will occur with other versions/channels (Dev, Beta, Stable).
Is there a timeframe for updating pdf.js to MV3?
Thx

[Rob--W]

I'm working on it. Hoping to finish it before the end of the month.

[Rob--W]

I have submitted an update to the Chrome Web Store, tagged as https://github.com/Rob--W/pdf.js/releases/tag/chrome-4.6.126.

This includes the preparatory work from #18651 and the final work in #18681. Compared to before, the main missing functionality is an alternative for file_browser_handler in Chrome OS (originally requested at #4185). Earlier I mentioned file_handlers (https://developer.chrome.com/docs/extensions/how-to/web-platform/file-handling-chromeos) as the alternative, but since I don't have ChromeOS to test with, and little time right now to set up a virtual environment, I'll leave it unsupported until there is renewed demand for it.

In Chrome 128+ the MV3 extension behaves as before; in Chrome 127- there is a content script-based fallback. The content script-based fallback (4327502) results in a pretty URL. I may consider adding an option in the future to use the content script-based fallback, because that results in a readable URL (instead of chrome-extension://oemmndcbldboiebfnladdacbdfmadadm/ in front of the actual URL).

[qwer1304]

@Rob--W Here's a reason to add the fallback as an option: Unless the URL is readable, pdf.js rendered pages cannot be saved in tab groups - see https://issues.chromium.org/issues/331796399. Of course if the URL can be made readable in other way, that'd also be welcome.

[shivaprsd]

I don't think it has to do with the readability of the URL, but with the protocol. The fallback method (at least the one I suggested) still redirects the page to a chrome-extension:// URL, while Chrome seems to support only HTTP/S for saved tab groups at the moment.

Unless Chrome updates its policy, the only way to support this would be to go back to the document.write() hack used at the beginning, which I don't see is likely to happen.

[qwer1304]

@shivaprsd @Rob--W I ran Chrome version 133.0.6835.3 (Official Build) canary (64-bit) (cohort: Clang-64) with --disable-features=DeclarativeNetRequestResponseHeaderMatching flag and the URL became readable (w/o the chrome-extension:// prefix) AND I could save a tab group with a file opened in the extension. So, IMHO it'd be VERY desirable to make the URL readable in all Chrome versions.

[Rob--W]

I have considered adding an option to force the inline behavior. It adds a delay in loading the viewer, but I can also see the appeal of having a pretty URL.

Feel free to file a new issue and assign it to me.