As of Firefox 56, it is my understanding that non-multiprocess-compatible extensions will no longer be supported, which is currently in nightly. Even if I were able to make OverbiteFF MP compatible, however (there were some technical hurdles to be overcome when I tried), it is highly dependent on XPCOM and Firefox 57 will be the end of that. As a result, OverbiteFF in its current form will cease functioning with Firefox 56. It will, of course, continue to work with TenFourFox and Firefox 52ESR, so I would recommend switching to 52ESR as a stopgap if you need to run XPCOM-dependent extensions like this one and are not lucky enough to have a Power Mac. For Firefox Android users, Overbite Android works wonderfully as an external application and Firefox Android will hand Gopher URLs to it; I use my own work on a Google Pixel XL with Android 7.1.2.
Unfortunately, there is no way to make OverbiteFF compatible with WebExtensions, even with reduced functionality: no one has implemented TCP socket access for extensions, and the protocol handler support is not only incomplete but actually intentionally excluded the Gopher protocol in URLs (so I can't even implement it like the old Overbite Chrome, which rewrote requests for any of the available Gopher->HTTP gateways). I'd submit a patch to whitelist gopher for the latter but there's been no motion on dealing with the standards clash that caused it, and there's not even an API description for WX socket support, let alone code written to implement it.
Clearly OverbiteFF is hardly alone among extensions in these requirements (for example, uProxy, Chatzilla, FireFTP and FireSSH will all stop working too), but I'm particularly bitter about this because its genesis came from the protracted end of Gopher support in Firefox 4. The tl;dr from that bug was, paraphrased straight from Mountain View, it's being yanked and you can't stop it, so learn XPCOM and write an add-on and maintain the feature yourself. Well, I did, it worked, people used it, and now it's going to stop working and unless motion occurs on these APIs I won't be able to make it work ever again in the future. You can post all the happy talk about how wonderful the end of XPCOM add-ons is for paying back Gecko's technical debt and I'm not going to dispute that, but that doesn't mean it doesn't suck. On the eve of WebExtensions' full takeover it feels like yet another broken promise.
Please, let's see motion on these and related APIs soon.