LiveView form phx_change firing with _target = "csrf"

Phoenix Forum Questions / Help
, ,
1

I have my forms setup as per the liveview form generators.

Sometimes I see this error occurring, where the form is posting with the hidden CSRF as the change target, which doesn’t have a handler, then the view collapses. It somewhat unnerving.

Is this a dev-hot-reloading issue? Should I have a dummy handle_event that does nothing and matches anything “just in case”?

no function clause matching in

Web.Live.Component.handle_event("validate", %{"_csrf_token" => "...", "_target" => ["_csrf_token"], "form" => %{"values" => "..."}},
1 Like
2

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?

3

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
3 Likes
4

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!

5

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 :slight_smile:

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

1 Like
6

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.

1 Like