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

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

Postponing on 📌 EntityFormController should load auto save state if it exists Active

📌 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?

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.

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).

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.

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

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

Back on this

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

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.

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

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

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

glad the solution wound up being so elegant! Merged.

Tested changes on branch 0.x , following scenarios :