Does anyone have any experience mangling browser autocompletion with LiveView? I know this is a general very frustrating topic, but the LiveView programming model makes it a bit hard to implement the regular solutions of hidden inputs (visually breaks validation as well as LiveViewTest), generating garbage input names (names need to match the Ecto schema, would require some very nasty hackery) and general vanilla JS solutions are hard without phx-ignoreing the whole form (why even use LV at this point?).
My mind is currently at creating a macro that will create two different versions of every schema, one normal and one with deterministically generated field names and switch between them just before reading and just before persisting. This is pretty insane (not to mention awful for debugging) so I likely won’t do this
Anyway, just wondering if anyone has thought about or dealt with this.
There are hacks you can do like generating “junk” name input attributes, (<input name={generate_field(:name)} value={...} />) but of course this isn’t going to cut with LiveView without doing a whole bunch of trickery.
Yes, I’ve had this problem with Chrome based browsers ignoring autocomplete for address fields.
I jammed in non printing characters into the label (remove the underscores) S_204;treet Add_204;ress
A hack yes, but i couldn’t find another way at the time and haven’t revisited it. I didn’t need to do anything with the name attributes.
This worked for my scenario, I’m not sure what it will do for screen readers (my scenario is for a small in house app where screen readers were not a requirement).
I think third party fillers are the culprit, but I’m also not sure. It’s certainly not just an us-problem as there is a bunch of info on it out there. Our problem is that in user testing a non-tech-savvy user was using some kind of auto-completer (we’re trying to find out which one) and it filled in a required field they’d scrolled past and was off screen! In any event, our app is of the nature that form auto-completion never makes sense. Users are always adding completely different data and we’d rather just disable auto-completion across the board to avoid confusion. Case in point: it took us quite a while to realize what had happened with that user (we had a recording but again it got filled off-screen) as we first assumed it was a bug on our side.
Also, the “hidden field” thing is just a technique for doing this where you have the real fields as hidden fields and the visible ones as junk name attributes. This isn’t possible (or not easy) in LiveView. Even outside of LiveView it’s not ideal.
By filled off-screen you mean the field was not visible to the user while they were filling it because it was scrolled out of the viewport or something or because you placed it in a deemed-invisible part of the screen so you can fill it programmatically?
Anyway, filling hidden fields with values typed into junk fields would require having something like two forms (of fields) where the one with hidden fields gets submitted while the one with the dummy (but real looking) ones does not.
Your problem here is two fold:
copying/syncing those values from dummy fields to hidden fields
validating server-side the hidden fields while showing the errors in the feedback for dummy fields
You can do this in LiveView, but you’ll either need a JS framework for #1 or write the input field event listeners in a hook yourself. Personally, I still use AlpineJS. I have it locked at v3.10.3 before it went completely incompatible with LV streams in v3.12.x+. Supposedly, you can also use Petite Vue which supposedly has most of Alpine features, including model used for input fields.
As for #2, it’s simple. LV supports (used to support? - I’m still on phx-feedback-for) providing a different field for feedback, so you can have your dummy fields use your hidden fields’ feedback.
I think might be misunderstanding. I was just providing some “classic solutions” that I’d rather not use because they are all too complex with LiveView (and sorta terrible in general). But I also I missed providing some context. So it’s this:
The user neglected to fill in a required field, then kept scrolling until the field was off-screen. They part I wasn’t clear about is that they were using and auto-filler that fills in fields they aren’t even focused on as they go. So it ended up filling in the required field they’d missed with some junk it thought it was correct. When the user hit save the forum successfully submitted then presented them with data they were surprised to see.
My CTO found an interesting potential solution I have yet to tried but will later today and can report back. In a nutshell, you make all fields readonly and toggle that attribute on focus/blur. If it works, this would play really nicely with LV since it can be done with JS commands.
What if you created a schema just for the form with your non-traditional field names, load it in your mount function, use it as normal and convert back to the original on save.
To be honest I don’t recall the exact reason, but I think it was just to make the field editable when needed, otherwise it would not even look like an input field.
