TextArea.Text returns "Undefined" when using Grammarly in a WebApp

I recently found the culprit of a bug that was unreproducible on my end and on different browsers. I installed the Grammarly Chrome extension and a few days later I reproduced a bug that a few of my clients had been complaining about for a few months.

When getting the text from a TextArea with “TextArea.Text” it returns “Undefined” when using the Grammarly extension.

I still have to look into this more but I was wondering if anyone else has had this issue or if it would even be worth making a bug report with Xojo?

Thanks,
Alex

So that was it !

I got a couple of these on my sites web forms and did not understand where it was coming from.

Confirm this is the issue.

Will investigate and report, if I find a workaround.

In the meantime, you definitely want to file a bug report describing step by step how to reproduce the issue, preferably with a sample project.

I quickly looked at the way Grammarly takes over. And there is no simple solution. Apparently, Grammarly uses its own TextArea, which explains why Xojo gets nothing. Indeed the text is not where it should be.

I suspect Grammarly expect a submit HTML tag which is not present, since Xojo works otherwise. Not simple at all.

OK. There is no way to detect Grammarly before the TextArea is focused.

When it becomes focused, Grammarly takes over and it becomes possible to detect it.

This in the GotFocus event of the TextArea does it :

self.ExecuteJavaScript("if (document.getElementById('"+self.controlID+"').innerHTML.search('grammarly') != -1) {window.location.replace('#grammarly')}")

It will add #grammarly to the URL, so it can be detected in Session.HashTagChanged. Then there are two possible ways to proceed :

  • Instruct the customer to switch off Grammarly, which can be obtained by clicking the switch off icon that appears when the mouse is hovered over the lower right corner of the TextArea (cumbersome)
  • ShowURL a mailto:yourname@youraddress.com so it triggers the default mail client.

I went to their site to see if there is an API that could be used to switch it off, nothing.

It could be possible to inactivate Grammarly some other way, but that requires some hacking.

For myself, I am going to remove that pest. It is far too invasive for my taste.

Here is what I did on my site. If I detect Grammarly, I pop a dialog offering either to switch it off, or to use the default mail client.

mail form app

Posted to Grammarly support today :

[code]I use Xojo Web from https://www.xojo.com to create my mail form. Unfortunately, it seems Grammarly interferes with the data available to the application, resulting in “undefined” as value for the TextArea.

See https://forum.xojo.com/39275-textarea-text-returns-undefined-when-using-grammarly-in-a-webap

I looked for developer support on your site to no avail, or mention of an API that would enable me to work around that.

Is there any way to catch the value of a TextArea when Grammarly is used ? Alternatively, would it be possible to inhibit it to prevent this annoying bug ?

Thank you.

Michel Bujardet
Match Software[/code]

Hopefully they will reply with useful advice.

In the meantime, I perfected the way my app linked to above reacts to the presence of Grammarly. When user tabs or clicks into the TextArea, if Grammarly is present, he is rerouted to a page that shows an HTMLViewer containing a simple HTML form where apparently Grammarly does not hook. And I process the form in HandleURL.

Thanks for looking into this bug, quite interesting what is causing it. Please let us know if you get a response from Grammarly.

Alex

Received today :

[code]Dear Michel,

Please accept our apologies for this issue.

The technical team is aware of the problem and they are currently working on it.

Unfortunately, this will not be a quick fix and I cannot provide you with an estimated timeframe, as the developers will need some time to analyze the cause of this issue.[/code]

Seems they don’t give a damn :confused:

[quote=320835:@Michel Bujardet]Received today :

[code]Dear Michel,

Please accept our apologies for this issue.

The technical team is aware of the problem and they are currently working on it.

Unfortunately, this will not be a quick fix and I cannot provide you with an estimated timeframe, as the developers will need some time to analyze the cause of this issue.[/code]

Seems they don’t give a damn :/[/quote]

Rats, I guess we got the classic

Thanks for all the effort you put into resolving this issue, it helped a lot.

In the meantime you could use the code to detect Grammarly and present the user with a message that politely passes the blame onto Grammarly. If you have enough users they should file enough complaints and maybe Grammarly will put some time into the issue.

“Unfortunately this app is not compatible with Grammarly due to the way Grammarly hacks the page. Please disable Grammarly to use this app.”

[quote=320947:@Tim Parnell]In the meantime you could use the code to detect Grammarly and present the user with a message that politely passes the blame onto Grammarly. If you have enough users they should file enough complaints and maybe Grammarly will put some time into the issue.

“Unfortunately this app is not compatible with Grammarly due to the way Grammarly hacks the page. Please disable Grammarly to use this app.”[/quote]

In the past, I have sent users complaining to services that I use and have found it quite effective at getting things fixed.

Like this bug that allowed players of a game to have admin level access.

Look at what I did on my site. Visit it with Grammarly on. It is mostly transparent to the user, does not penalize people using Grammarly.

Wow … I have had a mysterious problem that randomly appeared on several systems for students in a university environment for the last year or maybe longer.

Finally today one of them was obviously pretty good at “connecting the dots” and after exchanging a few emails he decided to look at the plugins installed with his favorite browser (Chrome). When he disabled Grammarly things worked.

So … it appears that my only solution is to catch the problem with a bit of JavaScript and tell the user that Grammarly is not compatible. Well at least it won’t be a mystery why the characters they type are never saved.

Ahhhhh … Web programming is such a kludge of things under the hood. This “trick” also sounds pretty dangerous in terms of what could be done to intercept text and send it somewhere else.

Thanks for documenting the problem and the JavaScript workaround.

My solution is currently when I detect Grammarly to send the user to a plain HTML form with a regular submit button.

It is possible to do the same, and point to handleURL to process the input.

[quote=347861:@Mark Strickland]Wow … I have had a mysterious problem that randomly appeared on several systems for students in a university environment for the last year or maybe longer.

Finally today one of them was obviously pretty good at “connecting the dots” and after exchanging a few emails he decided to look at the plugins installed with his favorite browser (Chrome). When he disabled Grammarly things worked.

So … it appears that my only solution is to catch the problem with a bit of JavaScript and tell the user that Grammarly is not compatible. Well at least it won’t be a mystery why the characters they type are never saved.

Ahhhhh … Web programming is such a kludge of things under the hood. This “trick” also sounds pretty dangerous in terms of what could be done to intercept text and send it somewhere else.

Thanks for documenting the problem and the JavaScript workaround.[/quote]

[quote=347898:@Michel Bujardet]My solution is currently when I detect Grammarly to send the user to a plain HTML form with a regular submit button.

It is possible to do the same, and point to handleURL to process the input.[/quote]

If you don’t care about your users being able to use Grammarly, you can disable it all together with this code in the open event of the textarea’s you wish to disable.

ExecuteJavaScript("document.getElementById("""+me.ControlID+"_inner"").setAttribute(""data-gramm"", ""false"");")

This will tell Grammarly to not mess with this textarea.

Alex,

Does this code disable Grammarly just for the one TextArea where you place it in the Open Event?

What happens if Grammarly is NOT installed?

Thanks, Mark

Not knowing Grammarly, I would think it applies only to the text area that has that attribute.

I can tell you that users without Grammarly won’t notice a thing because it’s only an attribute on the text area.

I did find this when searching for a “disable-all” kind of developer setting for Grammarly: https://stackoverflow.com/a/45086263
If the code still works, I would definitely use this method.

[quote=348034:@Mark Strickland]Alex,

Does this code disable Grammarly just for the one TextArea where you place it in the Open Event?

What happens if Grammarly is NOT installed?

Thanks, Mark[/quote]

I believe adding such attribute as data-gramm: False will simply do nothing. Just try his code in a small project in the IDE.

The code will only disable Grammarly on the textarea where you added it to the open event. Grammarly just doesn’t hijack the textarea and leaves it alone, the same as if you disabled the extension.

Has anyone found anything on this issue since the last post? We are running into the problem, as well. Alex’s workaround allows the text area to work, but it negates the benefit of Grammarly! Additionally, I suspect there is another method available since Grammarly works with the Xojo forum. Any ideas?