So far, vast majority of patches (just subjectively) are related to either css fixes or fixing css selectors in Caprine logic (shortcuts or other systems). That's the thing that changes most ofthen. The one we can't really influcence much are css fixes because when they happen, the only thing we can do is create a new release with a fix. The one we can influcence are css selectors.

Once they change and break, most of the time we just patch it up and send out a new release. The issue reports are usually " is not working" and it's up to us to track down what the root cause of it is. It doesn't usually take much time but in case of #1881 it took quite a bit of time to track down what the actuall casue of the issue was (it was a css selector for something else altogether which blocked the execution of code).

Right now elements are queried with document.querySelector or elementReady functions and they could return a null or undefined respectively. Throughout the whole codebase, this is handled by using non-null assertation operator or optional chaining operator which either just "makes the code work" but could throw errors at some point (which happens) or doesn't throw anything altogether and just nothing happens which is painful to debug. It's not that use of these operators is bad, to me it just feels like it's implemented with an expectation that query selectors wouldn't change.

My recommendation for making maintenance and fixing issues easier is to log in some way what queries fail exactly so once an issue occurs, user could just paste the log into the issue report and maintainer could very quickly track down the issue and fix it. Caprine is already having trouble handling all the changes in Messenger website so this would help a lot imho.

The logging I had in mind is writing failed queries with timestamps and any other useful information to a file which would be cleared at every start (so it doesn't clog up the disk if users restart Caprine in sane intervals). On report an issue button in help menu, Caprine could upload or paste directly the log to the issue that's being opened so users wouldn't need to dig around Caprines local files. It seems like the easiest solution and it should add too much to users workflow. The whole refactoring would of course thake some effort but I think it would pay off.