Browser Extensions: a Cautionary Tale
Formerly “Why we parted ways with Grammarly”
Update 2017–10–26
Grammarly took our report seriously and I’m very happy to report the error is now completely resolved!
A big thank you from Kayako and all our customers 👏
Original
For the past year, we’ve seen reports in Kayako’s bug tracker showing a handful of mysterious JavaScript errors. We scrutinised them every which way, but they evaded capture and seemed to be largely silent failures. Eventually we had to relinquish the chase.
Recently we upgraded to Ember 2.15.0 and the new Glimmer 2 rendering engine. Glimmer 2 is much stricter than its predecessor. Our mystery silent errors suddenly became noisy failures with clear call stacks.
We rolled back the upgrade and started investigating. It was clear something was mutating the page and making it impossible for Glimmer to do its job. A few breakpoints later, and the culprit became apparent: the Grammarly browser extension.
Digging around in the debugger revealed that the extension mutates the DOM in significant ways. Not just the DOM around our rich text editor, either. It appears to be mutating any DOM where the cursor lands.
Glimmer 2 is designed to be highly efficient, on the assumption that it’s running against stable DOM. With Grammarly in the mix, the stable DOM guarantee is gone — and with it, our ability to reliably render our app.
All this has left us in an awkward spot. We know our customers and colleagues get substantial value from Grammarly. We don’t want to outright block it but… we kinda have to.
So we started wondering: how many other apps are incompatible with Grammarly?
It seems we’re in good company. Major apps and popular open source libraries all report incompatibilities, not to mention our friends on Twitter:
Our customers may not be thrilled with our decision to block Grammarly, but hopefully they’ll understand our predicament.
To complicate matters slightly we don’t seem to be able to actively block Grammarly from our end. We ought be able to apply a data-gramm="false" attribute to everything but our rich-text editor, but it doesn’t seem to have the desired effect.
Grammarly do maintain a blocklist that we can submit our domain to. There doesn’t seem to be a formal process around this, but we’ve been in touch with their support and engineering teams and are waiting to hear back.
For now, we’re informing our Grammarly users that they may experience problems:
Coda
We know that engineering for the web is challenging. Grammarly’s extension is particularly ambitious and honestly it’s not all that surprising that compatibility problems have arisen. The blocklist is a good step, but it’s a shame to lose functionality altogether, particularly on sites that are all about writing.
Perhaps there’s no way to engineer the extension such that it doesn’t cause problems for modern web apps.
Whatever the situation, we’d love to know what Grammarly’s engineering team are thinking, and how they plan to address this.
Update 2017–10–25
Grammarly have added Kayako to their blocklist.
This helps in the short term, but in the long term we still don’t want our customers to miss out on Grammarly’s amazing service.
We’ve also heard back from their support team with the following:
Thank you for letting us know about the bug, and please accept our apologies if our turnaround on blocking Grammarly on Kayako was slow. The video you sent helped our development team realize we might have some issues with the latest version of Ember. We’re investigating this further right now, but, unfortunately, we have no ETA for the fix to it yet.
Thank you for your patience, and please feel free to reach out with any further questions.
