I am trying to fill a website with the help of a greasemonkey script.
This website has some required fields and I can't submit the form when they are not filled in.
Now, I have the following problem:
I fill the required fields using jQuery's .val. When I now click the submit button - even manually with the mouse - then it says that some of the required fields are not filled in.
When I click in one of the affected fields with the mouse and then click the submit button again, it accepts the value and proceeds.
My question is:
How do I figure out which event the website listens to? Or:
How can I trigger the validation of the fields from my script?
Update: I tried the following command directly in Chrome's developer tools' console:
jQuery('#ext-comp-1080').click().focus().focusin()
.val('my value').change().blur().focusout()
Most often, the validation is tied to a blur event.
In jQuery, you would use:
$('#thingToBlur').blur();
That said -- I have never triggered events through a UserScript, so I'm not sure if they will correctly hit the element in unsafeWindow.
If you need to force-ably run JavaScript on the page (and that includes firing the events there), see this question:
UserScripts & Greasemonkey: calling a website's JavaScript functions
Since after you change the file by using .val() and then you click into a field and click submit it most likely listens on change or blur event.
// set value
$(selector).val(value);
// trigger click
$(selector).click();
// trigger change or blur
$(selector).change();
You could also do method chaining if you wanted.
Related
I'm trying to simulate an actual tab key press in JavaScript. I don't want to focus on the next element or anything like that, I just want to make it seem like the tab key has been pressed.
The reason why is because I am building a form JavaScript class where I want to be able to use the enter key just like tab. If someone is using a native BROWSER autocomplete, I need to fire the tab key to capture the selected autocomplete response. If I just move to the next input it won't capture their autocomplete selection and leave the field blank.
Any thoughts?
I don't think it's possible; an article about DOM events here ...mentions that firing an event doesn't trigger the default result of the user action, for security reasons; the script should not be able to simulate user interaction directly. You will have to simulate the behavior the keypress causes (such as focus on a field), instead of trying to actually simulate a keypress. You probably won't be able to interact with the browser's native autocomplete functionality, unless the browser explicitly provides a means for you to do so.
Edit:
See also: [https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input#attr-autocomplete] (Autocomplete HTML attribute)
See the issue happening here:
https://gfycat.com/BelatedLawfulBighorn
The issue is that until the user interacts with the page (I just click inside the password field in this example), JavaScript can't read the password field if it is auto-filled by Chrome. Is this on my end? Is this some security feature built into Chrome?
To rule some things out, here's what I've tried and none have worked:
Using vanilla JS
Programmatically triggering a click somewhere on the page
Giving any of the input fields focus on page load
Giving any of the input fields focus on page load after a timeout of a few hundred milliseconds
Solved my own problem!
If I put everything inside a form, and instead of listening for the "enter" keydown event, I just listened for the "submit" event on the form, then JavaScript could read the value of my password field.
It is not possible to read the values until the user interacts with the page.
The reason is, that events have the isTrusted property. "The isTrusted read-only property of the Event interface is a Boolean that is true when the event was generated by a user action, and false when the event was created or modified by a script or dispatched via EventTarget.dispatchEvent()." (from https://developer.mozilla.org/en-US/docs/Web/API/Event/isTrusted).
Chrome autofill values only become readable with a isTrusted=true event.
Note: window.scroll() always has isTrusted=true. But it doesnt make the autofill values readable!
I ran into an incredibly obscure-seeming bug and want to document it for posterity. Here’s what happened:
I’m displaying an HTML form to the user with many text fields and a submit button at bottom. Just above the submit button is a warning message that appears or disappears depending on whether the user has filled in all the required information. During testing (automated using Capybara, or manual in the browser) I fill in each field down the page, then click on the Submit button, but the first click doesn’t register. A second click submits the form as expected.
I found that if I disable my custom Javascript, no second click is required. After some process-of-elimination I determined that one Jquery line was responsible for the failure: $(‘#warning-message’).hide();. Comment out this line, and filling out and submitting the form works as expected. Re-enable this line, and form submission requires that extra click. What the frak?
I eventually figured out this was because, both during manual testing and when simulated by Capybara-webkit, when you click on an element like a submit button, that’s registered as a specific X/Y coordinate on the screen. You're not clicking on the DOM element, you're clicking on a coordinate. Because of the (lazy) way I set up this page, when I fill out all the required elements then click Submit, upon clicking the submit button a Jquery change event is triggered which causes $(‘#warning-message’).hide();, which in turn causes the submit button to jump up outside of the area that I had clicked on, so the submit event never gets triggered in the first place because the browser doesn't realize that I clicked on a button.
I’m still not clear what to make of this, but it’s definitely not a bug per se, so much as a misunderstanding (on my part) of how browser events are handled. I’ve worked around the issue by wrapping the warning div in a fixed-height container so unrelated Jquery change events can't cause the submit button to jump around.
Anyway I hope this helps someone.
Situation: I have a form for the user to change their profile.
The form has input fields with event listeners attached for the onchange event so I can tell if the user has made any changes to the form. One of those fields is a password field.
In the case where the browser is set to remember passwords, when the form loads, it fills in the password field and triggers my listener.
Workaround:
I have set a timeout to reset my dataChanged flag after the page loads. Not very elegant. It seems that crawling the event.callee.caller stack is not recommended, non-standard, and unlikely to distinguish user- from browser-initiated events.
Question:
Is there a way I can determine events triggered by the user interaction (and javascript) only?
I don't want to cancel the event though, I just want to ignore it.
Clarification on choice of event:
This code is in our form-handling js library used throughout numerous applications. We need to know if the field has actually changed its contents so we can warn the user on leaving the form that data has not been saved. It is also used to trigger recalculation of other co-dependent fields.
Using onkeyup/onkeypress will trigger when the user presses non-editing keys like Tab, cursor-arrow, Shift etc. We want to avoid having to store the contents as loaded, and compare that to the content after onkeyup to determine whether the contents have actually changed.
Browsers also trap conditions where the user edits the field, changes their mind and presses ESC or CTRL-Z - onchange is not triggered. Event onkeypress fires many times during that process.
Therefore we would want to stick to onchange as the event of choice since it designed for our purpose - fire when content actually changes, once only when user exits the field.
Maybe you can set autocomplete="off" on the username and/or password field to stop the browser from auto-filling them
You can simply use onkeyup to handle this:
While loading your window you don't need to attach events to the
onchange of the fields so they can be autofilled by the browser.
And onkeyup of a field you will attach the event to its onchange so
the onchange event will only fire only if the user really changed
this field value.
For example:
HTML:
<input type="password" onkeyup="giveOnchangeEvent(this)"/>
JS:
function giveOnchangeEvent(input) {
input.onchange = function() {
//give the actions you need to do here
}
}
And that should do the trick.
EDIT:
To solve all the problems stated in your EDIT, you can use onfocus instead of onkeyup and append the onchange listener only and only if the input is focused by the user, and this way the browser auto filling actions will not count anymore.
Just change the onkeyup with onfocus in your input:
<input type="password" onfocus="giveOnchangeEvent(this)"/>
Note:
This approach avoids only the first onchange (of the browser) which is fired when the window loads.
I have an asp.net program in which I place a marker on a google map when the address in a textbox is changed. This Javascript is triggered by the onchange event. However I have noticed that if the user does not 'tab' out of the box before clicking submit, the event does not fire. Is there a way I can fix this?
I think what you are trying to achieve is impossible. the onchange event, happens only when you lose focus on the element. You could use onkeypress, onkeydown or onkeyup to get that change quicker. The problem here is that the value of the textbox is going to be changed by the click of an external element and therefore, you cannot bind it directly to the textbox.
If you know exactly what the clickable elements would be, you could add a click event to each one of them, pointing to a function that would test the textbox current value against the latest known value and if they were different, do whatever you want to do. But i don't think that's the case...
following your comment, you should add a submit event to the form, that would compare the current state of the textbox before submitting the form...