I’m fully aware of how it works regarding save selection vs copy saved to clipboard. The point is, while it may not be expected for the setting to be set to false, it should be accounted for. And while I can certainly understand your not recognizing this as an issue (you probably never thought of it, and I don’t blame you), it’s clear it is an issue that will affect anybody trying to protect their privacy by setting it to false. As I said, it would obviously be ideal if the add-on could be modified to still work properly even if this setting is disabled, but at the very least it should warn, and/or you should warn users in the add-on’s description, of the issue.
You say the lag shouldn’t relate to the function of the add-on, but it’s precisely the function of the add-on that’s presenting with said lag, so I’m not clear on what you’re actually trying to say there. Normal copy/paste works perfectly fine regardless of whether the setting is enabled or disabled, and the lag is only an issue with TMC. Lag may not be the best word to describe it, as that seems to suggest a slowness, when it’s actually an issue of the clipboard contents being offset, but I think I made it clear what I meant.
Also, to your comment that dom.event.clipboardevents.enabled only comes into effect on pasting to the clipboard, that’s not my understanding of it. From what I’ve read, it applies to even selecting text, as well as copying/cutting it, which is the point of disabling it for privacy. With it enabled, websites can see everything you select, copy, cut, and paste. If it only had an effect on pasting, that wouldn’t be the case.
It may be that the issue can’t be fixed, and that’s fine. If it’s a limitation of disabling that setting, and nothing can be done about it, or it would take more time and effort than you can (or are willing to) spend, then so be it. But at least now you know about the issue and what’s causing it.