Hatch: Chrome Extension Requires Redevelopment

[Chris Sharp]

Per this blog post: https://blog.chromium.org/2024/05/manifest-v2-phase-out-begins.html, Chrome extensions built on Manifest V2 will no longer be supported after June 2025. The Hatch extension page is already showing a warning banner saying "This extension may soon no longer be supported because it doesn't follow best practices for Chrome extensions." ( https://chromewebstore.google.com/detail/ppooibdipmklfichpmkcgplfgdplgahl?hl=en-US&utm_source=ext_sidebar )

Not sure of the full impact of this, but we need to assess it.

[Garry Collum (gcollum)]

Just adding this as a reference https://developer.chrome.com/docs/extensions/develop/migrate

[Chris Sharp (chrissharp123)]

https://developer.chrome.com/docs/extensions/develop/migrate - documentation to assist with migration.

[Bill Erickson (berick)]

Here's a branch to update to Chrome manifest v3:

https://git.evergreen-ils.org/?p=working/Hatch.git;a=shortlog;h=refs/heads/user/berick/lp2076921-hatch-manifest-v3

To test in Chrome, enable developer mode on the extensions management page, load unpacked extension, and point to the extensions/app directory in Hatch. Note the generated extension ID, then modify your local org.evergreen_ils.hatch.json file to use the new ID. (Make a backup of the original, though, to recover).

FIREFOX:

One issue I encountered is that Chrome and Firefox v3 manifest are incompatible, specifically with regard to background "scripts" vs. "service_workers".

https://developer.mozilla.org/en-US/docs/Mozilla/Addons/WebExtensions/manifest.json/background#browser_support

For now, I've created a separate Firefox manifest called "manifest.firefox.json". I was able to load the extension without errors (in extension debug mode), but did not test in Firefox. Related, this will presumably mean some Hatch doc updates are required for building the FF extension.

We need testing for both Chrome and Firefox.

[Bill Erickson (berick)]

Added a 2nd commit to bump the Hatch version in both manifests to 0.4.0.

[Jeff Godin (jgodin)]

Tested in Chrome stable (128.0.6613.186), Beta (130.0.6723.44), and Dev (131.0.6753.0) on Windows 10 with a previously-working Hatch install.

- I disabled the installed 0.3.3 version of the Hatch Native Messenger extension.

- Enabled Developer Mode in the Extensions section of Chrome settings

- Used "Load unpacked" to load the new extension from Bill's working branch.

- Changed the ID of the extension in C:\Program Files (x86)\Hatch\extension\host from the published extension's ID to the locally-generated ID of the "Install unpacked" extension.

- Tested printing and general staff client functions.

When done, I removed the unpacked 0.4.0 version of the extension and re-enabled the existing 0.3.3 version, reverted my changes to the org.evergreen_ils.hatch.chrome.json file, and disabled Developer Mode in chrome://extensions

All functionality appeared to work as before.

The only issue I encountered was cosmetic, and only visible with Developer Mode turned on in chrome://extensions

After navigating to a page that uses Hatch, then performing an action that navigates away from that page to a non-Hatch using site (like, loading the login page, verifying the expected hatch-stored workstations are listed, then entering https://example.com/ in the address bar):

An error indicator / button appears next to the (loaded unpacked) Hatch 0.4.0 extension.

Selecting that leads to a list of errors with a single entry:

Unchecked runtime.lastError: The page keeping the extension port is moved into back/forward cache, so the message channel is closed.

Context
Unknown
Stack Trace
:0 (anonymous function)
Nothing to see here, move along.

It seems at least one other Chrome extension has encountered this recently, but while their issue tracker is public, their source does not appear to be.

In any event, the error seems cosmetic, and while we might look into silencing it, there doesn't seem to be noticeable impact to functionality.

Bill and I briefly discussed rollout plans on IRC, though it seems our Chrome Web Store options for testing rollout / having a beta are less useful than similar options in the Google Play Store.

Rollout may be as simple/boring as releasing a new version with limited percentage, rolling up that percentage over a few days, and being prepared for a rollback if needed.

https://developer.chrome.com/docs/webstore/rollback

The boring part of course being the one where we don't need to do a rollback. :-)