Page data form values-in-progress not retained for Media Library (and perhaps other) fields

Created on 30 June 2025, 24 days ago

Overview

  • Go to the XB interface for an entity that has a field that uses the Media Library widget.
  • In the page data form, make some edits to the field using the media library widget as well as changes to a field using a simpler widget (page title or some other text field FE).
  • Do not publish your changes
  • Switch to editing a component in the layout so the form changes. Note that I can only make this switch if I add a component to the layout... after I add media I'm unable to click a component and have its form appear That may warrant its own issue if it isn't part of the solution here
  • Return to the Page Data form, note that the recently-changed value of the text field is intact, but the changes in the Media Library widget are not.
  • However, if you publish the changes, those recent changes including the not-in-the-form media library widget changes are published.

Proposed resolution

  • Not sure yet, but worth noting this is in the page data form, so it does not use transforms, so it aint that
  • This might be related to the inputs with missing values being ones added via AJAX vs the render array

User interface changes

🐛 Bug report
Status

Active

Version

0.0

Component

… to be triaged

Created by

🇺🇸United States bnjmnm Ann Arbor, MI

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

  • Issue created by @bnjmnm
  • 🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

    I think this is a duplicate of 📌 EntityFormController should load auto save state if it exists Active

  • 🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10
  • 🇺🇸United States effulgentsia

    📌 EntityFormController should load auto save state if it exists Active is in. Is this issue now fixed as well, or is there more to do here that the other one didn't cover?

  • 🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

    Confirming this still occurs after 📌 EntityFormController should load auto save state if it exists Active - I think it is now a FE issue. Will investigate.

  • Merge request !1232Issue #3533289: Always mount the page data form → (Merged) created by larowlan
  • 🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10
  • 🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10
  • 🇬🇧United Kingdom jessebaker

    I have been testing this and the issue described is fixed, at least partially. When returning to the Page Data tab the selected image is correctly displayed. However after leaving and returning to the page data tab, the remove image button no longer functions correctly as the entire widget is removed from the DOM (as shown in attached video).

    Furthermore, the same issue described in the IS is also present for media widgets in the component instance form (leaving the form and returning means the selected image is no longer shown).

  • 🇫🇮Finland lauriii Finland
  • 🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

    Furthermore, the same issue described in the IS is also present for media widgets in the component instance form (leaving the form and returning means the selected image is no longer shown).

    I think this means we're going to have to mutate the slice after AJAX calls, its ick but with the requirement to 'make existing Drupal forms just work' we're stuck between a rock and a hard place.

  • 🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

    Came up with a different approach.

    Rather than mutate the form HTML in the slice for both the component and page data forms, instead invalidate them on umount if the form_build_id was changed during rendering. This means any ajax operations that update the form trigger an invalidation of the cache when the form is unmounted.

    Seems to work in manual testing and was able to write an e2e test to show it is working, switching tabs doesn't clobber things.

    So if you're just switching tabs we keep the cached form around and its snappy.

    If you make a change to the form that triggers something AJAX-y the next time we mount we make sure to fetch a fresh form because the cached one is stale and doesn't reflect the new state

  • 🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

    This reveals a fail in multi value widget handling
    But it looks as though that exists in HEAD too, the error is that dragging and dropping doesn't trigger an update to the server and autosave

  • 🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

    Back on this

  • 🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10
  • 🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

    Pushed this forward a bit but still failing on multi-value widget

  • Pipeline finished with Failed
    16 days ago
    #543053
  • Pipeline finished with Failed
    15 days ago
    Total: 810s
    #543426
  • Pipeline finished with Failed
    15 days ago
    Total: 830s
    #543452
  • 🇺🇸United States bnjmnm Ann Arbor, MI

    I added 3533289-if-select-value-change-triggers-react-onchange as a draft MR which approaches the tabledrag issue differently - any programmatic changes to the select element are relayed to the onChange callback.

    As noted in the MR, if my changes are accompanied by me commenting away the useEffects added to DummyPropsEditForm and PageDataForm, the widget-multivalue.cy.js test is able to get several scenarios further, though it still eventually fails. Although it's not a complete solution, my hopes it is helps surface info that helps us get there.

    Also worth noting
    I was running into other problems with widget-multivalue.cy.js until I removed the existing components from the layout. More info is in a comment within the test.

  • 🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

    Went back to the start on this one.

    Started by splitting 🐛 Reordering items in a multi-value field doesn't update auto-save unless the user makes another edit Active for the existing issue with drag and drop in HEAD as the priority of that is lower than the bug here.

    Then dropping down to the root of the issue, it is that switching tabs in the side panel causes the form to umount.
    This means any AJAX modifications to the form are lost.
    And then when we switch back, we restore the form from the cache in the slice, which doesn't have the ajax modifications.

    So instead of trying to work out when AJAX modifications occur, I looked into the tabset component and realised we can prevent the component from being unmounted with the forceMount option.

    And this was the sauce.

    We still need to trigger invalidations when the component is unmounted, and that is when we use full page preview or the code editor, so I added code for that.

    I then tried to reproduce this with the components input form and could not.

    I think the difference with that is we have the query params that tracks the current values of the props when using the slice cache and as a result the form is already being correctly invalidated when we need it to. I added additional matching tests for the component inputs form to verify this and they passed without any changes in HEAD.

    So the new changeset is much smaller:

    We make sure the page data form remains mounted when switching between tabs
    We make sure the page data form cache is invalidated when we come back from preview or code editor
    Test coverage for all of the above.

    The issue with tabledrag is split to 🐛 Reordering items in a multi-value field doesn't update auto-save unless the user makes another edit Active

  • 🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

    larowlan changed the visibility of the branch 3533289-if-select-value-change-triggers-react-onchange to hidden.

  • 🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

    This is now passing and the changes are much smaller than previous iterations 🎉

  • Pipeline finished with Success
    14 days ago
    #544464
  • Pipeline finished with Skipped
    14 days ago
    #544603
  • Pipeline finished with Skipped
    14 days ago
    #544605
  • Pipeline finished with Skipped
    14 days ago
    #544606
  • Pipeline finished with Skipped
    14 days ago
    #544607
  • 🇺🇸United States bnjmnm Ann Arbor, MI

    glad the solution wound up being so elegant! Merged.

  • Tested changes on branch 0.x , following scenarios :

Production build 0.71.5 2024