Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Simulate keypresses when filling forms instead of just pasting content #140

Closed
madduck opened this issue Aug 28, 2021 · 10 comments
Closed

Comments

@madduck
Copy link

madduck commented Aug 28, 2021

Is your feature request related to a problem? Please describe.
Many forms these days use JavaScript for input validation as the user types, and consequently, if the user does not type at all, submit buttons may stay disabled, or errors are reported. It's bullshit, but welcome to the Web of 2021. If I use FHC to fill in a field, no events are generated, and unless I then edit the field, e.g. by adding a space and removing it, the checks often fail.

Describe the solution you'd like
We've had a similar issue with PassFF, and this is how it was solved: passff/passff#249

@hmijail
Copy link

hmijail commented Dec 10, 2021

I'm seeing something that sounds like the same issue: FHC fills most of the fields as expected, but the moment I try to interact with the remaining field/checkbox/whatever, all the fields get reset.

@madduck
Copy link
Author

madduck commented Dec 10, 2021

I'm seeing something that sounds like the same issue: FHC fills most of the fields as expected, but the moment I try to interact with the remaining field/checkbox/whatever, all the fields get reset.

Yeah, this is because more and more forms unfortunately use JavaScript to reinvent the basic functionality of forms: data are stored not in the browser fields, but in memory, and updated only on keypress. At various times, checks are run, and the memory data written back to the browser fields. If FHC filled in a field without generating the events monitored by the JavaScript wheel reinventions, then it never propagates to memory, and thus the field contents gets overwritten with the nothingness stored in memory.

@stephanmahieu
Copy link
Owner

I will look into this....

@quazgar
Copy link

quazgar commented Oct 20, 2023

I would like to add more specific information to this: When working on a site which uses the React framework, the user has to manually maybe add a space and delete it again, because no events are triggered by this otherwise excellent addon. Since this may lead to data loss (I press the submit button but not all the data is known to the application), I would be glad to see this shifted from a feature request to a real bug.

@stephanmahieu
Copy link
Owner

stephanmahieu commented Oct 21, 2023

My add on does nothing with submitted forms in relation to text-fields. It is only other html controls like checkboxes and radiobuttons that are stored upon submit. The reason is that classic html submit-buttons are rarely used nowadays. Submits from standard submit-buttons can be detected but more often you see buttons or links that trigger custom handling on a webpage. There is no way for any add-on to react or intercept custom submit-like actions, so this add-on will buffer anything you type into editable fields and store that at short regular intervals.

So when working with a site that uses the React framework, at the moment you start typing into any field, I expect the add-on to detect and store the text you typed.

It could be however that javascript magic does strange hidden things with the text you type, like the html field that receives your typed character might be instantly removed and added to an overlayed field which ultimately displays anything you have typed. Thus the inputbox stays empty! This is often how wysiwyg editors work (see Ace for instance). It can also be that the magic only happens after a click on a button or a link. It is not unthinkable that the React framework offers such editable fields out of the box too.
This is also why it is so hard to capture user typed text from fields on a website, while it is easy for the eye too see what you have typed, on html level it becomes increasingly difficult to find and extract that text.

See also closed issues with label: "custom page handling"

@madduck
Copy link
Author

madduck commented Oct 21, 2023

@stephanmahieu the issue isn't about submit buttons. It's about frameworks these days not taking the content of an input at submit-time, but rather keeping a shadow cache based on keypress, and using that. Case in point: I paste information into a field, e.g. with FHC, and the framework thinks that the field is still empty, because only keystrokes are registered. There is plenty of this about.

Extensions like PassFF have worked around this. When they fill in form fields, they don't just set their value/content using the DOM, but instead, they generate keypress events for the individual characters, which then fill the form, but also satisfy the frameworks. It's a massive hack, but it is what the Web has come to… Thus, if FHC could do the same, it would be a win!

@stephanmahieu
Copy link
Owner

stephanmahieu commented Oct 22, 2023

Aha, okay I understand now.
For inspiration: passff/passff#182

@stephanmahieu
Copy link
Owner

Incorporated in release 2.5.8.0

@madduck
Copy link
Author

madduck commented Nov 1, 2023

Thank you! I will test it soon!

@quazgar
Copy link

quazgar commented Nov 6, 2023

Works for me now, great!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants