Develop Reference

simulating keypress on Input on webpage using chrome.debugger.sendCommand

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.

Honeypot spam trap conflicts with browsers auto-fill feature

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...

HTML disable wrong autocompletion

I am currently working on an Angular web-application.
This application consists of two single-page-applications:
- Login-Page, accessible over "domain/login.html", containing login-logic.
- Application-Page, accessible over "domain/", containing the concrete application.
If you try to access "domain/", the server redirects you to "domain/login.html", if you are not logged in yet. Otherwise you will get the Application-Page (no redirect).
In the concrete application there is a Change-Password-Page, where you have to enter the old password and the new password (twice).
The problems start, if you say "save password" on the login-page. The saved password is automatically filled inside the "Old-Password" field.
Also there is another page having a text field and a password field directly after each other (where the text-field is for a phonenumber) and the browser inserts the username into the "phonenumber"-field and the password inside the password field. This is really strange, as the fields have different names and ids and are even on another page (again one is "/login.html" and one is "/")
As this behaivor is incorrect i would really like to disable it. However I was not able to do that until now.
What i tryed:
autocomplete=off, for form and input-tags. This seems to be ignored by most modern browsers.
Two hidden (display:none) input-fields (text + password) on first position. Seems to work for Firefox, but Chrome and Opera still give you the possibility to autocomplete the fields.
Use type="text" for password-field and change it to password inside javascript-code. Again Opera and Chrome still give possibility to autocomplete those values.
So I am looking for a (clean) solution to turn off the wrong autocompletion.
Is that somehow possible?

I have been encountering this issue lately, specifically with chrome. It seems that
autocomplete="off" || autocomplete="false"
are not being picked up anymore by Chrome (or most other browsers as far as i'm aware). I found the following sources helpful :
Chromium (which i believe is what a lot of Chrome is based on) has the following code that shows the regex that is used when finding fields to populate with Chrome's autocomplete:
https://cs.chromium.org/chromium/src/components/autofill/core/common/autofill_regex_constants.cc?sq=package:chromium&g=0&l=262
I feel like they only other work around that I have found is to follow these conventions :
https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/autocomplete
Or at least make sure that you give an attribute that's disimilar enough from the above list so it that wont get picked up by autocomplete features.

Showing num keyboard for currency on mobile devices with validation

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?

Read only textfield editable via inserted javascript?

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.