5 ms·
Another nice thing about Grammarly is that the plugin just blindly detect contentEditable inputs and start screwing with their content. This very much breaks mo
by marijn 9y ago
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".
- mariushop 9y agoSpot on, had a similar problem on an web editor I work on.
- LocalPCGuy 9y agoIt 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)
- Zelphyr 9y agoNot to mention, because of the placement of their hover in the bottom-right its next to impossible to resize a textarea with their plugin installed.
- k_sh 9y agoYep. 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!
- btown 9y agoAs 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 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.
- philipodonnell 9y agoThis 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.
- rgossiaux 9y agoYes, 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).
- fareesh 9y agoLastPass 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?
- untangle 9y agoI 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...
- alanh 9y agoI 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)