I am experiencing a persistent issue with the new Authoring MFE in the Open edX Teak(tutor 20.0.3) release. When working on a Authoring MFE Unit page, clicking to add a new XBlock (specifically Problem or Video MFE editors) but then selecting “Cancel” or closing the editor without saving still results in a blank block being added to the unit.
Steps to Reproduce:
Open a unit in Studio (using the new Authoring MFE).
Click on the Problem or Video component button to add a new block.
Once the editor/selection modal appears, click the Cancel button (or close the modal) without selecting any problem type or video source.
Refresh the page.
Actual Behavior:
A blank “Problem” or “Video” XBlock appears in the unit outline after the refresh, even though the action was cancelled.
Expected Behavior:
No new block should be created if the “Cancel” button is clicked before selecting a component type or saving.
Does anyone faced the same issue ever? Please do suggest the solution if any. Thanks.
Hi @meet1 . What you’ve highlighted is a long-standing issue with the Course editing experience. It stems from how old legacy editors (before the Authoring MFE) worked: when you created a new Problem or Video with those old editors, it automatically created a blank item for you, which you then had to Edit or Delete in a separate step. The Authoring MFE editors are using that same workflow, but it also immediately opens the new editor for you–this is more convenient usually, but as you’ve found, it does make the “Cancel” button more awkward, because it seemingly leaves behind a ghost component.
As of Teak, the new Content Libraries editing experience solves this issue. It’s built on a new backend that does not require the component to be saved before editing it, so hitting “Cancel” will not leave a blank component behind. We plan to rebuild the Course editing experience on that new backend so we can fix “Cancel” (and several other issues) but it will take at least a couple more releases for us to do that.
@kmccormick Thanks for the detailed explanation. Just to clarify, I’m using the new MFE Problem and Video XBlocks with the React-based unit editor, not the legacy editor. I completely agree with the Content Libraries functionality, though many course creators prefer the direct approach of adding a single video XBlock to save time.
After investigating the issue, I found that the Authoring MFE creates a unique locator (usage key) on the backend as soon as the “Problem” or “Video” button is clicked. This is necessary for handling metadata and uploads, but the current code lacks a cleanup process if the user cancels. I’ve adjusted the logic to delete the ghost component when the “Cancel” button is clicked, ensuring that the temporary ID is removed if the user doesn’t complete the action. This approach aligns with how the backend API handles creation and saving as separate steps. But somehow I believe that this is not most feasible and accurate solution of this issue, which are your thoughts regarding this? Please do share your valuable insights.
@mgmdi if I remember correctly, you implemented the fix to Library Authoring which made it so that the editors work without saving a blank component first, correct? If so could you link to that PR?
@meet1 maybe Maria’s PR would provide some insight on how challenging it would be to apply the same fix to the Course Authoring interface. If the same fix is too challenging to apply, then I think the delete-after-cancel workaround you’ve developed might be the best option.
Yes, @mgmdi could you please share the PR for the Library Authoring fix? It would be really helpful.
@kmccormick, you are absolutely right! I also explored whether we could simply stop the API call that creates the component object on just that initial xblock button click, but after reviewing the code, it appears this would require a fundamental architectural change. Delaying creation until “Save” would mean introducing a create-on-save workflow, which risks breaking the Ducks pattern and network layer, and would likely impact image uploads and editor settings that depend on having a parent component ID.
That`s why I also believe that the most relevant fix is to allow the front-end to Cleanup (delete) that ghost component.