Inconsistent behavior for extracted text media in Isle-DC UI

[DonRichards]

Description:

During testing, I've noticed that the user interface no longer allows users to replace extracted text media after it has been added. This change seems to have been made intentionally, but I'm unclear on the reasoning behind it.

While I understand the potential implications of this design decision, I'd like to propose an alternative approach: making the replacement feature optional. This would allow us to retain the existing behavior while still providing users with the flexibility they need when working with extracted text media.

Specifically:

• The current implementation seems to silently discard the ability for users to replace extracted text media.
• I recall a conversation in a tech call where this change was discussed, but I don't have any details on the rationale behind it.
• I'd like to propose adding an optional feature that allows users to explicitly enable or disable the replacement functionality.

Request:

Could we revisit this design decision and consider implementing the replacement feature as an optional feature? This would give us flexibility in how we handle extracted text media while still providing users with a consistent experience.

[rosiel]

I'm curious what you mean by that. I went into the sandbox and on the extracted text media, the extracted text file can be removed and replaced, and there's also a textarea that can be edited. What are you seeing?

[DonRichards]

This is likely an issue with my variation of isle-dc