Setting work type for a PURL reservation fails from the work show page

[peetucket]

Once you reserve a PURL, you need to set the work type to edit the work. There is a modal that shows in this situation before you get to the work page. In fixing this issue: https://github.com/sul-dlss/happy-heron/issues/3570 (users potentially going directly to the edit work URL), we discovered that setting the work type from the work show page doesn't work, even though it works from the dashboard or the collection list page.

To reproduce:

1. Reserve a PURL within a given collection.
2. Visit the work detail page for your reserved PURL.
3. Click the pencil icon next to the title - you should get the work type modal.
4. Select a work type and click submit. It will set the work type but you will get a blank page with a "Content missing" error.
5. Refresh the page and you are back on the Work detail page, and now you can edit it as normal.

If you follow the same process, but click the pencil icon for the reserved PURL on the dashboard, you will see it correctly redirects to the edit page after setting the work type.

Suspect something not working correctly in turbo.

This PR adds some test expectations in https://github.com/sul-dlss/happy-heron/blob/main/spec/features/purl_reservation_spec.rb to verify the error: https://github.com/sul-dlss/happy-heron/pull/3571/files Uncomment them out when this is fixed

[edsu]

I see this error on the JavaScript console when trying to edit the title:

Uncaught (in promise) Error: The response (200) did not contain the expected <turbo-frame id="workDetailsFrame"> and will be ignored. To perform a full page visit instead, set turbo-visit-control to reload.

[edsu]

When the pencil is working the What type of content modal has a Continue button that is in a <form> that targets /reservations/{id}. This results in a HTTP 303 redirect to /works/{id}/edit.

When the pencil is not working the What type of content modal has a Continue button in a <form> with target=/reservations/{id} but the form is within a turbo-frame with an id=workDetailsFrame. Clicking the button triggers a POST to /reservations/{id} which results in a HTTP 303 redirect to /works/{id}/edit BUT it also seems to trigger a GET to /works/{id}/details.

The HTML for edit view doesn't contain a <turbo-frame id="workDetailsFrame"> and causes the JavaScript error that seems to prevent the proper rendering of the page.

The question is, why are we seeing the requests to the edit and details URLs when it is not working?

[edsu]

FWIW reverting #3571 does not fix this.

[edsu]

Perhaps this isn't important but it looks like there is a doubling up of identical <turbo-frame> elements when clicking through to the work type modal?