I'm working on a TamperMonkey script to automate a few things for me on a webpage.
On this webpage there is also an input-field which is giving me some headaches.
I can enter values in the field, but it doesn't get validated and the submit button remains disabled.
I can select the input programmatically by using
elmtsInputs[0].select();
after which I can enter the value from my keyboard without any problem.
However if I try:
elmtsInputs[0].value = "0.5";
The value 0.5 appears briefly before it's being reset again to the default 0.0
So there is some sort of validation happening on the input-field that notices that the value wasn't typed.
Also when I type in an unauthorized value (basically any value greater than 1) it also shows a validation message to say the value is incorrect. So there is definitely validation happening.
I have tried multiple dispatchEvents but none of them worked.
After searching online I came across multiple sources that the problem is related to the isTrusted:false
issue where input coming from scripts are not trusted but keyboard input is.
When trying to look if there was any way to bypass this, I found some examples where the use of the Chrome Debugger was used a solution.
chrome.debugger.attach(target, "1.2", function() {
chrome.debugger.sendCommand(target, "Input.dispatchMouseEvent", arguments)
})
However, I haven't found any useable example on how to implement this.
Can someone shed some light on how this should be implemented?
Thank you.
Related
I'm not sure if this is a cefsharp issue or just Javascript one, but when testing filling in a form on a test site i'm coming across this:
When cefsharp is filling in the fields, it's placing the values over the text instead of inside the input field.
document.getElementsByName('email')[0].value = 'test#test.com';
So after reading (i'm sure it's a focus issue) i tried:
document.getElementsByName('email')[0].focus();
Which should have worked by all accounts, but it never showed any difference from the image above.
I even tried:
document.querySelector("//*[#id="email"]").click();
The xpath to the field, still no difference.
Is it some how needing set from a cefsharp point of view? any tips in the right direction would be great.
I spent the better part of yesterday trying to make the AutoComplete control required. The API doesn't have a required attribute and onNewRequest doesn't fire if the textbox is blank, onBlur has a bug and doesn't work, and I'm not sure how to hijack handleSubmit (redux-forms-material-ui) to check if that field is empty. Also I put that control in the list of fields to validate but nothing fires for that control. What am I missing?
Shortly after writing this question I realized code another developer wrote was stepping on the validation. Nothing is wrong with making the control required field by passing it an error message if the control has no selection.
So I've read through a bunch of other similar questions but I'm at a loss as to what I can do.
I have an input box that takes a currency so I'd assume clients would put $2.50 in. I'd also like to have the num keyboard display when a user clicks on it. However if I use type="number" it allows the entry of $ but the event no longer has that content in it and hence I cannot validate it.
I thought about using the keypress function, and although there isn't a value I could convert the code but this seems overkill.
I've tried putting novalidate on the form but it doesn't seem to do anything. I've also seen an attribute event.target.willValidate that I thought could be doing something as it's always true but no validate doesn't seem to affect it.
I've also seen one solution that flicks it between text and number to show the correct keyboard but turn off the validation. This also seems a bad work around.
Anything else I could try?
I have a form with a read only field for display/submit to the next page purposes.
However, I noticed using developer tools in Chrome, I was able to add an id to an element, use the javascript console to select that element, and change its value. I submitted the form and what do you know - the next page acted on it as if it was the original value.
Now, there shouldn't be any problem with the people using the site I'm building, but it seems like a huge security flaw to me. Isn't the point of read-only to remain constant? If a savvy user to change it around, doesn't that pose a big problem? In fact, I didn't even think you could add and change attributes in chrome.
Please post your thoughts below, and let me know if there's a solution ("disabled" textfield, but setting the disabled property doesn't send the data to the next page).
NEVER trust input from a web form.
The user could, just as easily, remove the readonly attribute and edit the value. The readonly attribute is only something to help the user when filling out the form, so they don't edit a value expecting it to change, when your server actually won't let it be changed. So, always remember to code the behavior on your server first, and have the HTML form be a helpful guide for users to make the form easier to fill out (without having to submit the form several times to get relevant error messages).
To overcome this, if something is readonly and you do not want it edited, you could store the value in your database. Also, values provided by users should always be checked (and sanitized) as no amount of JavaScript, HTML, or CSS is going to prevent someone who knows what they're doing from adding new or changing/removing existing values.
The 'estimatedvalue' attribute of the opportunity entity is marked as being required. I have it on the form, but have marked it as being disabled, both through the Form UI customization, as well as using javascript, but some other javascript is re-enabling the form after I've disabled it.
The best solution I have so far is disabling the attribute from the callback of a timeout: setTimeout("CommonLib.setDisabled('estimatedvalue', true);", 1);. When the field loads, it loads as disabled, then some other js is enabling the field, then the callback from the timeout runs and disables it again, so you see the field go from grayed out, to black, to grayed out.
There are two other attributes that I've disabled and they stay disabled, but the estimatedvalue is the only one that is actually required, so I'm guessing it has something to do with that.
Any ideas as to what is re-enabling the field?
I dont think it has anything to do with the requirement level but #Anwar may be one explanation. Could you double check if some other custom script might be enabling the field?
I just tried following with the task where subject is the required field and it seems to be working fine:
Xrm.Page.ui.controls.get('subject').setDisabled(true);