LiveView form phx_change firing with _target = "csrf"

I have this exact issue. It’s rare enough that I haven’t noticed a pattern, but frequent enough to be noticeable. Are there any thoughts on what might be the culprit?

Most likely this is occurring due to the behaviour of form recovery following crashes or disconnects: the auto-recovered form has no context for the change event target, so it grabs the first form element and uses it as the target.

This could be verified by binding a custom handler for form recovery (by default it uses the phx-change binding):

<form phx-change="validate" phx-auto-recover="recover">

or with form helpers:

<%= f = form_for @changeset, "#", phx_change: "validate", phx_auto_recover: "recover" %>

then add the appropriate callback(s) to your LiveView:

def handle_event("recover", %{"_target" => ["_crsf_token"]} = params, socket) do
  # recover the form state after disconnect
  {:noreply, socket}
end

I can’t say I grok this, but I’ll give it a shot. I do have the liveview socket exposed on the window object as ls, and using the console to ls.disconnect() and ls.connect() did not reproduce the error. Which is good, I suppose, because otherwise auto-recover would never work.

Would it be too much to ask for some additional context around “the auto-recovered form has no context for the change event target” and why LV would grab the first form field (CSRF token) and use that as a target? Thanks!

Form recovery occurs when the socket rejoins following a disconnect or after recovering from an error. The form recovery event mimics a form input/change event however form events have a target property that indicates which form control dispatched the event. Recovery events have no such target, so we quite literally target the first form element.

The Phoenix.HTML.form_for helper by default generates a hidden input called "_csrf_token" directly following the <form> tag. This will always be the first form element unless you disable it with csrf_token: false.

Were you testing this in the dev environment? If so, did you disable LiveReload? There is a note about this in the link I shared above. FWIW I was definitely able to reproduce this purely client-side

If it helps, I made a gist with a more complete example: LiveView Form Auto Recovery · GitHub

I very much appreciate you taking the time to reply, @mcrumm. It seems I wasn’t fully understanding your reply, because I actually don’t have the same issue as OP, just one that looks a lot like it.

However, this thread made me look more closely at the log output, and this (annoyingly rare and inconsistent) issue seems to be due to the phx-change event being sent to the wrong LiveView. This is likely my fault, but now I need to dig deeper. Anyway, thanks again.