The Xojo forum doesn’t use the web app framework, its html. The easiest way would be to convert your textarea’s into html/“http form” textarea’s and leave the framework out of it. It depends on what you want your app to do?
[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]
I knew I saw that solution somewhere, thanks @Michel Bujardet !
FWIW if you have a container container control on a page that is not visible . and you fire this Javascript if there is any latency you will get a javscript error rendering the session useless.
Interesting, I haven’t experienced this yet. Good to know, thanks!
This is not good. I rely on this Java Script and I do have some containers invisible on certain pages, and those containers do have Text Area controls. I haven’t seen this problem, but i have very little latency at all (so far).
Has anyone heard of the Grammarly people have fixed this problem?
@Greg O’Lone Will this issue evaporate with the new web framework?
There is a very important place this issue arises. When a JavaScriptError is encountered, the Xojo WebApp will trigger the built-in JavaScriptError dialog, where the user can enter important information for the developer, in a text area control, and then press Send. But if Grammarly is active in that browser, the Send button will do nothing at all. No errors.log file will be written/updated and the JavaScriptError Dialog will not be dismissed.
Is there a way for me to use code to disable Grammarly for controls in that JavaScriptError Dialog? I know how to do that for this or that WebTextArea I created. But this dialog is built in.
I started a new thread on this here: https://forum.xojo.com/54108-javascripterror-and-grammarly-plugin
I would try to contact the Grammarly development team. They may have a solution.
We are doing something different with JavaScript errors in the new framework, but if you guys are running into issues, make sure theres a bug report or feature request and bring it to my attention.
The thing that surprises me about this is that a plugin that affects how our simple error dialog works must affect other sites. If I remember correctly, our dialog just submits a simple form so if the framework is somehow hosed, itll still send.
Grammarly installs probably a listener on the submit button. That is probably what messes up the black box of death.
The fact that the field returns undefined makes me think that they are intercepting the key events and then adding them programmatically. That may screw with our validation code, but Im not at my desk to check today.