fix: patch children of focused Form-Associated Custom Elements (FACEs)

[carlosescri]

I hope this helps someone.

Problem

When a Form-Associated Custom Element (FACE) has focus, onBeforeElUpdated in dom_patch.ts identifies it as a focused form input via DOM.isEditableInput() and returns false. This tells morphdom to skip the element and all its children.

For native inputs (<input>, <select>, <textarea>) this is correct, their value lives in the DOM and we don't want morphdom to overwrite what the user is typing. But FACEs are fundamentally different: they store their value in ElementInternals via setFormValue(), not in DOM attributes or children. Their light-DOM children are structural (e.g. slotted elements, in my case is a custom select web component with slotted elements) and must be patched normally.

How to reproduce

1. Create a FACE with static formAssociated = true that has light-DOM children managed by LiveView (e.g. a slotted button with a phx-click attribute whose payload changes on each render).
2. Give the FACE focus (click on it).
3. Trigger a server re-render that updates the children (e.g. via phx-change).
4. The server sends the correct diff (visible in WebSocket inspector), but the children in the DOM are never updated.

Root cause

document.activeElement === <my-face-element>   (always true for shadow DOM hosts)
DOM.isEditableInput(<my-face-element>)         → true  (formAssociated = true)
isFocusedFormEl                                → true
return false                                   → morphdom skips children

Solution

A new helper DOM.isFormAssociatedCustomElement() detects FACEs. When a focused FACE is encountered, the patch returns the element instead of false, which tells morphdom to update attributes and descend into morphChildren as usual. Native inputs retain their existing behavior.

Notes

• delegatesFocus: true on the shadow root does not help — document.activeElement is always the host element regardless of this setting.
• LiveView already has explicit FACE support (isFormAssociated(), isEditableInput()), and FACEs participate correctly in form serialization via FormData. This fix completes that support by ensuring their children are also patched.
• All existing JS tests pass (252/252).

[carlosescri]

My use case was found in a showcase of the component. I can pass a function that receives the selected values and you can return a JS command to be applied on phx-click. In my case it just displays a flash message with the provided values.

The problem was that those values weren't patched on form change and the JS command was never updated although values were present in the websocket patch response.

<Form.select_v2
  field={f[:other_country]}
  prompt="Select one or more countries"
  multiple={true}
  search={true}
  options={UISelectSchema.options(:countries_by_continent)}
  apply={&(JS.push("apply-selection", value: %{selected_values: &1}))}
/>

renders:

<ui-select
  id="ui-library_other_country"
  name="select[other_country][]"
  ...
  class="..."
  data-phx-id="m17-phx-GMBrixe-pkv_jRgE"
>
  <optgroup label="Africa">
    <option value="Egypt">Egypt</option>
    <option value="Nigeria">Nigeria</option>
    <option value="South Africa">South Africa</option>
    <option value="Kenya">Kenya</option>
  </optgroup>
  <hr>
  ...
  
  <button
    type="button"
    class="..."
    slot="actions"
    phx-click='[["push",{"value":{"selected_values":[]},"event":"apply-selection"}]]'
    data-phx-id="m18-phx-GMBrixe-pkv_jRgE"
  >
    <span class="...">
      Aplicar
    </span>
  </button>
</ui-select>

Before

The user selects a country and clicks on "Aplicar" (Apply). The phx-click of the button should reflect the value but it didn't.

After

[SteffenDE]

Quoting the README

JS contributions are very welcome, but please do not include an updated priv/static/phoenix_live_view.js in pull requests. The maintainers will update it as part of the release process.

Are you sure that this approach works with all form associated custom elements? I’m wondering if, should we merge this, we’d get bug reports from users that did rely on this behavior.

[carlosescri]

Are you sure that this approach works with all form associated custom elements? I’m wondering if, should we merge this, we’d get bug reports from users that did rely on this behavior.

Thanks for the response and the interest on this PR @SteffenDE.

Fast answer: NO 😅. That's why I've added a specific set of tests for this issue, which I should have done from the beginning:

• In main some of them should fail (they did)
  • Failed run: https://github.com/carlosescri/phoenix_live_view/actions/runs/29079639170
  • Draft PR just to see the code of the tests: https://github.com/carlosescri/phoenix_live_view/pull/1/changes
• In current PR's branch all should pass (they did)
  • Successful run: https://github.com/carlosescri/phoenix_live_view/actions/runs/29079591382

You should have access to all artifacts in case you want to review them.

Now I can say I'm more confident on the solution 😄.