That's really the point of having them, isn't it? To make the site work the way the user wants. In fact I'd say what it will actually achieve is less visitors to your site... they're just going to leave and go somewhere else.

I classify this along with the anti-right-click, disabling select/copy/paste, changing the status bar, resizing windows, and other general "DO NOT WANT" aspects of sites.

I wouldn't personally run something like this, but I've definitely experienced the frustration of having a user install an extension that changed my website, and then reported a bug in the extension to me.

Even when the extension is bug-free, it still adds a support burden. For instance, there's an extension that adds icons to usernames on my site. Users have asked me how to change their icon, and then gotten mad at me when I say I don't know.

It also adds a maintenance burden: Whenever I deploy various updates, I get complaints that the updates break one extension or another.

Not to mention, there are extensions not intentionally installed by users. For a while, there was some very common malware that rendered my website unusable. It added the text

    <script src="http://example.com/malware.js"></script>

    <script src="/legitimatescript.js"></script>

    <script src="/legitimates<script src="http://example.com/malware.js"></script>cript.js"></script>

How about explaining it better? Get them to show you a screenshot, and then you can point out the fact that it's not coming from code you served.

For a while, there was some very common malware that rendered my website unusable.

Perhaps that was a good thing, because it made you aware of its presence quickly.

You presume users understand what the difference is. Not all users are technical enough for that sort of thing.

Someone also points out a related problem: if the user complains on social media instead of directly to me. I don't always have the opportunity to explain at all.

> Perhaps that was a good thing, because it made you aware of its presence quickly.

Unfortunately, being aware of its presence didn't help much. I considered alerting the user that they had malware, but generally the only time a website tells a user they have malware is to scam a user (see: MacKeeper), and I didn't want users to see my site as untrustworthy.

https://github.com/Zarel/Pokemon-Showdown-Client/commit/95f2...

All of the things you mentioned are websites trying to break your expected behaviour. This is the exact opposite - your extension is breaking the expected behaviour and the website wants you to leave it alone.

I get to choose how this client-side Javascript runs because I get to choose how every kind of software runs on my own computer.

The problem comes if you install a browser extension (or acquire malware that installs a browser extension for you), forget about it, and then blame the website when the website stops working, often filing bug reports (increasing the support load of the website).

Just look at hacker news. Many posts have someone complaining how the site is broken only to find out they have disabled scripts or have a night mode extension, or disabled webgl but forgot about it, or they programed their router to drop all packets that were going to a url that included "google" anywhere in it (including mysite.com/google-blog-post, true story)

Longer answer: I install any such extension with full knowledge of their potential to cause breakage, and consequently my first reaction to a broken page is to issue a reload with the extension disabled.

The web being programmatically accessible and end-user-malleable is a strength, not a weakness.

It would be nice if there was some way to prevent users from reporting bugs if they have extensions modifying the website in certain ways, or at least warn them to try disabling their extensions first. I wouldn't even mind a whitelist for certain well-behaved ad blockers, but certain extensions are well known for being bad (many extensions _inject_ ads, which is a recipe for website breakage).

Perhaps you should move away from the "just throw some js at it" mentality and learn to design things in a more robust fashion, so that they don't depend on having to make assumptions about the dom.