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);
Related
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.
As you may know, Chrome does not support:autocomplete="off", autocomplete="nope", autocomplete="false" or even autocomplete="new-password" any longer.
That means, from time to time, I do get reports that honeypot traps are preventing users from submitting forms, since the trap input is being auto-filled, even if not shown.
The practice for setting the trap is wrapping a TEXT input with a display:none; element, so spam bots won't be able to figure its really hidden (unless they are smarter and they usually aren't), and if this input has contents, you won't allow the submission to go through, as the field supposed to be hidden and empty for regular users.
What's your practice in using honeypot traps while still having browsers ignoring the demand for auto-complete or auto-fill by using the above arributes?
My current solution (October 2022) for a honeypot field looks like this:
Move the input field out of the visible area using css
Avoid name attributes that Chrome looks for when autofilling, like email, address, etc.
Do not wrap the honeypot input element with other elements that contain such keywords in their label or in name attribute
If you are using FormFind (which analyzes a page's source code and extracts the 'action' parameter and the input tags will find hidden fields. Hidden fields will not stop a spambot.
FormFind will find all the fields on a form from the HTML source code. And once you find the input fields - and the 'action' parameter (which FormFind does find) - its easy to use CURL or WGET to 'submit' the form.
Although reCAPTCHA will help with spambots, the only technique that I have found (and what I use in my solution) is to have some JavaScript code that will change the form's action parameter on a onclick/onfocus event. And if you put a delay in the JS function that changes the action parameter, that's a bonus spambot blocker.
Using JS to change things (or even to fill in a hidden field, if you insist on using one) is a good technique. CUSL and WGET cannot process JS code. (There was an open source project that claimed to be able to process JS code, but it was abandoned a couple of years ago.)
The JS trick is what I use in my contact form at my free FormSpammerTrap.com site. Code is free and open source. And the contact form there uses my technique. Have not gotten any spam via a spambot (automated process) from there. And I am working on a newer version that will add delays to even further block spammers.
Anyone is welcome to request the code to try it out. No charge. No fees. No advertising. No $$ benefit to me, other than how I use it on my sites to block spam.
So, using hidden fields to stop spambots is not going to work well. You have to have more layers of defense against them. Using JS code techniques is another layer that will help block almost all spambots. (There's no 100% solution, but I think mine is close - and it's been around for a couple of years.)
I removed the name variable from the input tag and this resolved the issue of the hidden honey pot fields getting autofilled...
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.
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.
I have a text input field in my web page that I am using to collect a date (via the jQuery Tools .dateinput). The user does not need to be able to type into the field. A dialog box appears when the field is clicked on. This is a problem on my Motorola Droid, because I don't want the soft-keyboard to appear when the field is clicked.
I have tried input.blur() on focus and also setting the field to disabled and readonly. Setting the field to disabled has undesired side effects. Setting the field to readonly works in everything but the Android browser. The browser seems to recognized the "readonly" attribute (or readOnly via javascript), BUT the field does not actually become readonly. When you click it, the soft keyboard still appears and allows you to change the field.
I suppose that this is a bug in the Android browser. Can anyone come up with a clever alternative?
I used a workaround - since I didn't need to actually edit in the input field (like you, I was popping a date picker), I changed to a span with similar styling. The code is kind of trivial once you have the trick, and it's really app specific so I don't have any really for you to see.