Type of Request
Fast Track Change (small, low-risk improvements)
Feature Description
TL;DR
In Studio course authoring, clicking a "+ New Component" button creates the XBlock on the
backend before its editor opens. If the author then cancels the editor, the blank component
stays behind in the unit and has to be deleted by hand.
Proposal: cancelling component creation should roll back the block created for that editing
session, so cancelling leaves the unit exactly as it was.
Current behavior
- Open a unit in Course Authoring.
- Click Add New Component → Problem.
- The "Select problem type" dialog opens. Choose a type (e.g. Multi-select) and click Select.
- The problem editor opens. Click Cancel.
- A blank Multi-select problem is now in the unit, and the author has to delete it manually.
The same happens for Text and Video components, and for the new built-in PDF editor — any type
that eagerly creates the block and then opens an editor.
Expected behavior
Cancelling the editor without saving should remove the component that was created for it. The
unit should be left exactly as it was before the "Add New Component" click.
Why this is a Fast Track Change
The change is confined to the cancel path of the add-component flow, and only affects the
component types that open an editor immediately after creation (Text, Problem, Video, and the
built-in PDF editor). The remaining types in the Add Component menu — Discussion, Drag and Drop,
Open Response Assessment, Advanced, Library content, Item bank — never open an editor on
creation and are untouched.
That last point addresses the concern raised on #1809, that deleting on cancel "wouldn't make
sense with blocks where the user doesn't need to make any initial changes" — those types are
structurally outside this change, because there is no editor and therefore no cancel event.
Note on the blocker raised previously
On #3101 the concern was that a proper fix is complex because "image uploads happen in the
editor before the new XBlock has an ID."
That constraint appears to be specific to libraries, not courses. In
frontend-app-authoring, uploadAsset uses the block ID only on the library branch; the course
branch POSTs to /assets/<courseId>/, keyed on the course rather than the block. This is why
the Libraries V2 fix (#1574) needed to hold images in memory until save, and why that particular
constraint does not appear to apply to the course flow.
Not in scope
- Closing the browser tab or navigating away with the editor still open. An unsaved-changes
prompt already warns, but if it is dismissed the component remains.
- Changing when the block is created (the "create only on save" refactor tracked by #1482 and
#1809). This proposal is a rollback on cancel, which complements that longer-term refactor
rather than replacing it.
Prior related work
- #3101 — current open report for courses; the maintainer response invited a fix but noted the
complexity above. Still unassigned with no linked PRs.
- #2261 / #2293 — earlier report of the same behavior. The merged fix refreshed the unit so the
blank component became visible; it did not remove it.
- #1482 / #1574 — the equivalent fix for Libraries V2, explicitly scoped to libraries. Courses
were not changed.
- #1809 — umbrella issue on making content block creation behavior consistent.
Link to Product Proposal
No response
Status
New
Proposed By
Edly
Type of Request
Fast Track Change (small, low-risk improvements)
Feature Description
TL;DR
In Studio course authoring, clicking a "+ New Component" button creates the XBlock on the
backend before its editor opens. If the author then cancels the editor, the blank component
stays behind in the unit and has to be deleted by hand.
Proposal: cancelling component creation should roll back the block created for that editing
session, so cancelling leaves the unit exactly as it was.
Current behavior
The same happens for Text and Video components, and for the new built-in PDF editor — any type
that eagerly creates the block and then opens an editor.
Expected behavior
Cancelling the editor without saving should remove the component that was created for it. The
unit should be left exactly as it was before the "Add New Component" click.
Why this is a Fast Track Change
The change is confined to the cancel path of the add-component flow, and only affects the
component types that open an editor immediately after creation (Text, Problem, Video, and the
built-in PDF editor). The remaining types in the Add Component menu — Discussion, Drag and Drop,
Open Response Assessment, Advanced, Library content, Item bank — never open an editor on
creation and are untouched.
That last point addresses the concern raised on #1809, that deleting on cancel "wouldn't make
sense with blocks where the user doesn't need to make any initial changes" — those types are
structurally outside this change, because there is no editor and therefore no cancel event.
Note on the blocker raised previously
On #3101 the concern was that a proper fix is complex because "image uploads happen in the
editor before the new XBlock has an ID."
That constraint appears to be specific to libraries, not courses. In
frontend-app-authoring,uploadAssetuses the block ID only on the library branch; the coursebranch POSTs to
/assets/<courseId>/, keyed on the course rather than the block. This is whythe Libraries V2 fix (#1574) needed to hold images in memory until save, and why that particular
constraint does not appear to apply to the course flow.
Not in scope
prompt already warns, but if it is dismissed the component remains.
#1809). This proposal is a rollback on cancel, which complements that longer-term refactor
rather than replacing it.
Prior related work
complexity above. Still unassigned with no linked PRs.
blank component became visible; it did not remove it.
were not changed.
Link to Product Proposal
No response
Status
New
Proposed By
Edly