So, I have run across an issue where due to maintaining a state for an input field; breaks the user experience of the app when they use an extension like Grammarly in their browser. Problem as I figure is since the state is immutable and Grammarly changes the DOM without triggering an change. So in that the state doesn't change, and thus the changes from Grammarly are lost, it let's say that input is part of a form, and I hit submit. The data from reacts state gets sent down, not the visual changes grammarly made.
So my overall question is.. does anyone know of a method, means, or practice I can deploy to capture instances like this and work with them properly.
You can try to use MutationObserver for detection of external changes of the DOM nodes, and then apply them to the state like a regular input.
Re: For more information about Grammarly extension compatibility, you can check this thread.
And also, Grammarly will release developers guide in the near future.
Related
Im building a web app in React where the user can interact via various key strokes on the keyboard (don’t ask why, it’s what the client wants) but the issue I’m running into is that I’m updating values in the state/context when a key up event is triggered and the number of key ups is important but whenever the state changes React re-renders the component and duplicates the key up events causing unwanted behavior. I could be misstating the problem but I’m hoping someone has advice for a best practice approach for what I’m trying to accomplish in React. I’ve attached the listener to the entire document and I’ve tried a bunch of things to avoid the event being duplicated and when I check the number of listeners in the chrome console I only see one. Happy to provide any other pertinent info or code but there’s a lot of code since this spans multiple components.
Browsers like Firefox or Chrome offer to remember the password when you login for the first time on a page; this functionality autofills the corresponding user/password combination in the login form the next time the user visits said page.
My question is, is there any way to become aware that the browser has autofilled these fields? the event change does not fire; in fact, according to monitorEvents nothing fires. I've resorted to use an interval that periodically checks whether the fields are empty or not, but is there a better way?
I am quite sure Chrome does fire the change event. I have experienced it recently (by accident). It is also already documented in Chromium Issue 135307.
Not sure about other browsers, but if you are write a periodic check will probably be the only solution. This code seems solid.
I've been struggling to deal with a few forms that have users entering in a lot of repeat data. In these cases it helps users to have access to form history (ie. to select the name of a person they've sent multiple notices to, etc. The issue here is that in most browsers there is no event fired with a user selects a chunk of text from their form history. So with the help of a few other posts on stackoverflow I decided to use setInterval instead.
What I'm looking for now is feedback to spot anything that might be a bad idea and anything to make this better.
I have a demo of it here http://lab.atworkinthecloud.com/form-history-select/
I believe you shouldn't base your implementation on the behavior of the browser (remembering the history), which might or might not be available to the user.
If you want to design a useful interface, you should provide the access to the history yourself, or use features like autocomlete
since you trigger the handler so frequently , (and I noticed that you also bind the propterychange event), then why don't just bind the propertychange only, that will do it as well.
you don't need to bind all those events at all.
I met the same problem, but I still prefer to have a way that only trigger the hanlder after the user finished typing.
I'm developing a web application which requires long-running Ajax requests. Unfortunately, under Firefox, pressing Escape during a request has the drawback of killing the request and any information it was holding. This is rather annoying, as this can lead to all sorts of nasty complications if this happens at the wrong time. Therefore, I would like to deactivate this feature.
My first reflex was to intercept keypresses at the boundaries of <body>, to ensure that they would not reach the window. For this purpose, I installed a [keypress] event handler, just for events whose [keyChar] is 27, and had it invoke [stopPropagation] and [preventDefault]. And for a time, it looked like this was working.
Then, I realized that it wouldn't work when the user hadn't clicked anywhere on the window, as <body> event handlers never received the event. I tried to attach my handler to <document> or <window> to no avail, so I eventually ended up adding a [load] event handler and had it force focus to <body>. And for a time, it looked like this was working.
Then, I realized that when the user was editing an <input>, for some reason, once again, the <body>, <document> or <window> event handler never seem to receive the event. So, I added yet another [keypress] handler, intercepting with [preventDefault] on the <input> when the [keyChar] is 27.
For the moment, it looks like it's working. However, with the history of this bug in my application, I'm a tad pessimistic.
So, I'm wondering if there's a better -- and reproducible -- method. Recall that the bug seems to appear only in Firefox, so I'm quite willing to take a Firefox-only approach here.
I'd be worried about other nasty complications that will happen when the users choose a bookmark or otherwise navigate away in the middle of the request. You might want to look at why you're using long running requests and see if that's something you can change...
If it isn't something you can change (or even if you can) you should look at why your requests aren't fault tolerant. Is there a way to put the communication into transactions, and roll the latest one back if the connection is interrupted?
I know this is kind of an old thread but there's an active bug logged against Mozilla regarding this issue (which I'm also facing). See https://bugzilla.mozilla.org/show_bug.cgi?id=614304 for more info.
One suggestion from this bug is to intercept and prevent the ESC key press at the window level (as also mentioned by OP):
window.addEventListener('keydown', function(e) {(e.keyCode == 27 && e.preventDefault())});
This might have unwanted side-effects though.
Safari has a feature to prompt you if you're sure you want to close/refresh the page on which there are some forms which you typed into. This is useful in most cases, but in this case it's bugging me.
I'm hijacking the "submit" event on some forms and sending them to the server via XMLHttpRequest. However, Safari doesn't know that, so when I want to close the tab it displays that damn warning that form values have changed.
I know how to turn it off in OS X and I don't want that. I want to turn it off on this specific web page I'm building, and for all users with Safari. Surely there must be some JavaScript way—I don't care if it's proprietary to webkit.
Update: I tried this, but to no effect. Safari first warns about unsaved data, then triggers the "beforeunload" event.
if (Prototype.Browser.WebKit)
window.addEventListener('beforeunload', function(e) {
forms.invoke('reset')
})
I don't know Safari that deeply, but if you just submit the values and don't need them afterwards, why not simply reset the form? I would expect no change = no warning.
If you don't want to reset it straight away, you could even try hooking the reset command to the unbeforeunloadevent to do it when you close the page. Whether that works depends on when Safari checks for the changed form, though - before or after calling unload.
That's application behavior, so there mustn't really be any JavaScript way of modifying it. Every WebKit specific feature is documented pretty well, and I've never seen anything of the sort. Just clear your form fields if you're really that worried about it.
https://developer.apple.com/library/content/documentation/AppleApplications/Reference/SafariWebContent/Introduction/Introduction.html#//apple_ref/doc/uid/TP40002079-SW1
https://developer.apple.com/library/content/documentation/AppleApplications/Reference/SafariHTMLRef/Introduction.html#//apple_ref/doc/uid/30001261
The only way I see left around this is having a form consisiting of hidden inputs only, and a bunch of input elements that are not associated with the form. On submit, you fetch the values from the the elements, make your request and reset the internal form. You could even do the moving of the input elements out of the form via DOM so it would even degrade gracefully.
A lot of work and a bit hacky, but as far as I can see the only option if you can't change the workflow.
Try removing the action and method attributes from your form tag with Javascript after you bind submit. This way, Safari should no longer see the inputs as being part of a real form.