Future-Proof Your Browser Extensions: Smart Monitoring and Debugging Techniques

Browser extensions are everywhere, and they help make sites easier to use and even add new features!

Extensions however may be made to modify specific sites, and may rely on the Document Object Model to have elements unchanged, or perhaps the extension may intercept incoming or outgoing fetch requests to modify or extract data from. This is sometimes the only way for extensions to work, depending on how the site the extension interacts with, was made and deployed, and often leads to developers relying on a consistent DOM to insert new elements into the page.

There are sometimes landmarks which can be relied upon, such as elements with IDs which are only used in one place, or perhaps even icons, but if they move around, this could cause problems for any extension which relied upon the DOM remaining the same, but it's very likely that this will change over time.

The huge extension Return Youtube Dislike is very familiar with this problem of YouTube's DOM changing, and their extension encounters errors, which also cannot be always be diagnosed due to gradual roll-outs, where only a small percentage of users get the change. I suggested to them that it might be a good idea to just have the extension request their server and ask where to place the dislike button, which they implemented and they have had significantly increased reliability.

LighterFuel, my own extension, has also been affected by changes, when Tinder set their "Last Modified" headers on their image CDN to 1/1/1970.

These problems for me have led to a huge influx of support requests along with reviews asking me to fix the issues, and thankfully due to all these requests, I knew about the problem within the day.

How can errors be reported sooner?

Realistically, it's pretty janky to rely on user support requests to tell you that your extension has stopped working, so I decided to look into it more.

One amazing tool which I have recently discovered from being included in the Microsoft for Startups scheme, was Microsoft Clarity , a service which allows developers to see how their website is used, where the user clicks and it replicates the DOM in an iframe, so it's possible to visually see in your own browser a clone of what's happening on the user's browser. Clarity is also completely free, unlike Sentry which also works for browser replays.

This service does not typically support browser extensions however I managed to get it working, as Google's manifest v3 does not allow for remote code, it required some reverse engineering to be able to make everything work with local code. Here is an example I made on the Plasmo examples repo for adding Clarity to an extension, via injecting the javascript into the site.

This is an improvement, but these replays do not tell the whole story and they don't always give all the information that is necessary to debug and fix all errors that are encountered.

How can I know if something my extension relies upon changes?

Client side unit tests! This seems like one of the only times you'd want your unit tests to be actually deployed into production, however this solution has seemed like a good idea for me to use in my extensions, which rely on data being formatted in a certain way, so for example, if the JSON schema changes in an api that is being accessed, then you could know about it ASAP.

I've not yet implemented these unit tests in my extensions, however I have created an example in the Plasmo example repo here which I'll base my implementations off of. The idea is to run the tests where you handle the DOM or any other data, then the test function automatically fires off any failed tests to the background message handler, so it can be sent off to a server, or some service like sentry, so you can see what changed and how to fix it.

I've fixed my extension, now what?

Uploading a new version of an extension and waiting for it to be approved and published is a long and annoying process, it can take up to a week for a patch for a breaking bug to get approved and then it takes even more time to roll out as not everyone gets the new version at once.

In the meantime, the support requests and reviews do not stop flooding in and this is not a problem that's easy to counter.

As Chrome's manifest v3 bans remote code, it's quite difficult to fix extensions without just uploading a new version. The only way I could think of potentially coming up with a workaround, would be walk the line between building an "interpreter to run complex commands fetched from a remote source" and providing my extension with a formatted JSON document which specifies where to get data from in the intercepted requests, or where to place new objects into the DOM. This would take lots of time and effort which I feel wouldn't be worth doing for my projects, however I do plan on exploring this idea further and seeing what the chrome web store will accept.

Conclusion

I've outlined some new potential strategies to help find out about errors faster, then highlighted methods to fix them faster, although there is still scope for improvement as the delay from knowing about an issue, and having a fix deployed and published is around 3-5 days at best.

I also think that many extension developers could benefit from integrating services like Clarity into their extensions with "report error" buttons like I've added in LighterFuel, alongside adding unit tests to ensure that key elements their extensions interact with have not changed.

DOM = Document Object Model