Another nice thing about Grammarly is that the plugin just blindly detect contentEditable inputs and start screwing with their content. This very much breaks modern WYSIWYG web editors, which typically expect to have control over the editable content. Which more or less comes down to "move over page scripts, I'm a browser plugin, this is _my_ webpage now".
Yep. I recently had a client that kept having layout problems with an email template I had written for him, after he had edited the content in WYSIWYG.
Turns out Grammarly was injecting HTML into the editor, which in turn was being included in the email body!
As a web developer, setAttribute('data-gramm', 'false') is your friend.
For better or for worse, between browser extensions loaded by the end user, and "tags" injected by your well-meaning business analytics team - see my comment here: https://news.ycombinator.com/item?id=16314501 ), the extension ecosystem has become the new Internet Explorer in terms of compatibility testing. Luckily most of the workarounds are trivial, but it's essential to have good QA on actual client machines if you're doing, well, anything at all.
This will work fine until the next Grammerly decides that when you put data-gramm you meant to disable Grammerly, and their software is better so its fine to ignore that unless you add a data-whoever and on and on.
Or eventually web developers will start putting that stuff in by default, bootstrap will come with it, etc.. and these companies will see less and less traffic, and they'll start coming up with reasons to ignore it.
It was also breaking sites built on JS frameworks like Angular and Ember (probably others, those are the two I saw specifically) where the framework expects to be controlling the DOM (and Grammarly was messing with things causing out of context changes that the frameworks didn't expect)
Yes, after working on a rich-text editor this is now the only thing that I think of when I see things about Grammarly. In our case, we emailed the Grammarly devs, who shortly turned it off for our domains. I prefer this to turning it off on our end with the data-gramm attribute for probably obvious reasons (maintenance, cleanliness).
LastPass does this as well to input fields. Made it unusable for me. Haven't used a password manager since (was a couple of years ago). Has this problem been solved well recently?
I have been a 1Password user since ~2010 and never once has it ever made an input field or login form unusable for me. (I used LastPass briefly before, but vastly preferred 1Password's native apps and more secure architecture, which was completely validated when LastPass was hacked a few years later)
I do not have a problem with LastPass on input fields (including this one), nor do I recall one. Perhaps a setting was amiss or it was a platform-dependent issue. Grammarly, OTOH...
