stephanmahieu / formhistorycontrol-2

A browser Add-On to View and Manage form history entries (adaptation of v1 for web-extension and e10s)
https://stephanmahieu.github.io/fhc-home
MIT License
51 stars 14 forks source link

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

Closed madduck closed 1 year ago

madduck commented 3 years ago

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: https://github.com/passff/passff/pull/249

hmijail commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

I will look into this....

quazgar commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

Aha, okay I understand now. For inspiration: https://github.com/passff/passff/issues/182

stephanmahieu commented 1 year ago

Incorporated in release 2.5.8.0

madduck commented 1 year ago

Thank you! I will test it soon!

quazgar commented 1 year ago

Works for me now, great!