Simple Proxy for puppeteer extension rewritten

I have an extension that controls the proxy of a browser. Before the rewrite, it was pretty slim, written in plain Valina JS, and I didn't touch it for three years. 

But manifest V3 will be mandatory as of June this year, so I rewrote it. It took me a few hours, and I converted it into a Svelte TS extension. 

Added a few new features, like the possibility to auto-disconnect if the proxy is failing, start the proxy with the browser, being able to verify a proxy is valid, and dark theme(as default).

Extension when I first wrote it and even now was meant to be able to be controlled by Puppeteer. Before the mechanism was pretty easy meaning that you searched for background pages with Puppeteer then since the background page was a forever theard you could execute in that thread methods that were already defined in that scope. 

Now, I will again complain that not allowing persistent service workers is a mistake by Google. Manifest V3 had and continues to have a slow development cycle, and frankly, they added a lot of needed stuff that could have been achieved only using ugly hacks. 

So they did the correct thing and expanded the power of extensions; the problem is that there are things that they didn't ever want to back down.

A very notorious example is allowing persistent service workers. And I get it; it might get abused technically in the latest iteration of their docs; they allowed such a feature through consistent background pings. But documentation states that such practice is not permitted(for production extensions) only for "education" purposes or whatever that means. I think that is already super used in many extensions in the store, even if on paper, those extensions should not be allowed.

The reality is this feature is needed. For this extension, it is not at all, but there are hundreds if not more cases where you need that, and a persistent service worker is not a big ask. They only did that to increase performance, but if waking up the service worker is heavy, it will be much less performant than losing 60Mb of RAM by keeping the thread idle. 

The reality is that you can't guard against poor performance programming is so easy to fuckup the browser with the extension. I can do that in under 5 min, making an extension that will block your browser completely such that if you're not a technical person, you'll need to reinstall the whole browser. The way forward is to create a new permission called: "persistent" inform the user that the extension wants that permission, and let's drop the hacks.

An open thread can be much more performant than spikes that could occur when waking up a heavy thread in modern OS. We keep having more threads; for example, two decades ago, the average machine had like 50-100 threads open; now, probably, the average is in the thousands, and for one powerful server, well in the hundreds of thousands. 

The repo has an example of how to use it with Puppeteer. 

You'll probably need a newer version > 110 of chromium. 

I don't expect to do too many updates since the extension is simple, just if I find bugs or other issues. It had a few thousand users over the years that tried it out(and I didn't do any updates over the years since it was stable). I guess there aren't many people that need this extension. 

The primary use could be: 

• doing some scrapping with different IPs
• automation process where you need to change the IP
• or use it manually if you own some private proxy and want to change your browser proxy. 

So it doesn't have many applications, but it has some advanced hacks, like being able to wake the service worker from Pupetter using an internal extension page. I don't even know if anyone did that before. Anyway, it is on Chrome, and also, here is the repo link:

https://github.com/andrei0x309/simple-proxy-for-puppeteer-chrome-extension