Hatch Browser Extension Sometimes Fails to Respond

[Bill Erickson]

Evergreen 3.8 / Affects All Versions

The Hatch browser extension fails to correctly relay responses from the Hatch Java process back to the requesting browser tab.

One theory is the browser tab connect / message / disconnect messages are arriving sometimes in an unexpected order, causing an active tab to be removed from the set of tabs which may receive responses.

From a sample extension log where a failure occurred:

16:43:08.108 extension.js:89 new port connected with id 2
16:43:08.108 extension.js:113 Removing port 2 on tab disconnect
16:43:08.372 extension.js:92 Received message from browser on port 2

The first 2 messages typically arrive in the opposite order. In this case, port (i.e. Tab) 2 is still active, but removed from consideration before the 3rd message arrives.

[Lynn Floyd (lfloyd)]

I have seen this with Chrome 95.0.4638.69 and hatch 0.3.2 with extension 0.2.2 and Evergreen 3.7.1. Exact same thing happens.

[Bill Erickson (berick)]

I have a branch here that I hope to address the issue:

https://git.evergreen-ils.org/?p=working/Hatch.git;a=shortlog;h=refs/heads/user/berick/lp1954301-ext-tab-message-order

This branch is intended to solve the problem without requiring a change to the Java backend. However, the longer term solution would be to also apply some Java backend changes -- see commit for comments.

TO TEST:

* Checkout the Hatch working branch user/berick/lp1954301-ext-tab-message-order

* In Chrome, go to the Chrome Extensions page

* Disable the existing Hatch extension (for now).

* Enable Developer Mode

* Click the "Load upacked" button to load the modified extension.

* Select the extension-> app directory from the Hatch checkout.

* In the newly loaded extension, click Details -> Background Page for debugging.

* Modify your Native Messaging configuration to allow access to the modified app.
  ** See the ID: value in the extension description.
  ** Modify your local org.evergreen_ils.hatch.json file and change the "chrome-extension://..." value to use the new ID. (Keep a copy of the old ID handy though so you can recover it when done testing).
  ** org.evergreen_ils.hatch.json lives in different places with different names depending on the OS. See https://developer.chrome.com/docs/apps/nativeMessaging/#native-messaging-host-location

* Reload EG in the browser and confirm connectivity.

* The extension background page should now show logs like (will vary):
  ** "new port connected with id 186000000012"
  ** "Hatch responded to request on tab 186000000012"

* Test

* When done, recover your original org.evergreen_ils.hatch.json file/key and reenable the store version of Hatch.

[Bill Erickson (berick)]

Pushed a follow up commit that simplifies the tab differentiation logic. Note I have not yet tested this in Firefox.

[Jessica Woolford (jwoolford)]

I applied the fix on a library computer this afternoon and they'll get back to me tomorrow to let me know how it's working for them. For anyone else who would like to test on Windows 10, the path to org.evergreen_ils.hatch.json was this: C:/Progam Files(x 86)/Hatch/extension/host.

[Bob Wicksall (bwicksall)]

I also applied this fix on a known broken client and it immediately started working correctly. All pages are loading.

[Michele Morgan (mmorgan)]

This fix is also working perfectly for me.

I was seeing the white screen issue consistently in a newly opened Chrome session while logged into the Evergreen client on four different servers running different releases of Evergreen. The white screen consistently happened on all four servers when switching between the checkout and checkin functions.

I applied this fix to my Chrome browser and the issues immediately resolved on all four servers. After closing Chrome and relaunching the issues did NOT return.

I reverted to the old extension, closed Chrome, relaunched and the white screen issues immediately returned on all four servers. Re-enabled the new extension and the issues immediately resolved.

I will add my signoff shortly.

[Michele Morgan (mmorgan)]

My signoff branch is at:

https://git.evergreen-ils.org/?p=working/Hatch.git;a=shortlog;h=refs/heads/user/mmorgan/lp1954301_signoff

user/mmorgan/lp1954301_signoff

Thanks for the quick fix Bill!

[Jeff Godin (jgodin)]

Tests well on Firefox 96.0b3 / macOS 11.6.1 against Evergreen 3.7.2 and Evergreen 3.8.0.

I did not have the advantage of having a machine that was clearly exhibiting the symptoms, but I did confirm that the extension's console log showed the changed behavior after replacing the extension.

[Jeff Godin (jgodin)]

Pushed Bill's latest to master with my and mmorgan's signoffs. Marking Fix committed.

No changes to Hatch local install, just to extensions (hosted in and deployed from Firefox and Chrome "stores").

Once the new extensions have been built and uploaded, clients should update per their local settings, usually automatically.

[Galen Charlton (gmc)]

Marking as fix-released, as this fix was included in the 2021-12-14 Hatch update.