Closed
Bug 1255893
Opened 8 years ago
Closed 4 years ago
Attaching a file throws away unsaved edits
Categories
(developer.mozilla.org Graveyard :: File attachments, defect)
developer.mozilla.org Graveyard
File attachments
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: wbamberg, Unassigned)
Details
(Keywords: in-triage, regression)
STR: 1) start editing a document 2) edit, edit, edit. Don't save yet. 3) attach a file: select the file, name it, upload it Now the edits you made in (2) are gone. You will see the little "You have a draft from: ..." ...banner at the top, and if you choose "Restore" it will bring them back. But it breaks your flow, is confusing, and if you don't see the banner and make more edits, you're then forced to choose whether to keep the old edits or the new ones. This is made worse by the fact that "You have a draft..." doesn't tell you which edits would be restored, if you chose to restore. It turns out that there is already a bug for this: bug 961188, but it seems to be dormant :(.
Updated•8 years ago
|
Severity: normal → major
Keywords: in-triage,
regression
Comment 1•8 years ago
|
||
Good catch, this is an intended change done as part of the attachments refactoring to achieve a few things: 1) get rid of hideous (read: unstable and untested) JavaScript client code for the upload form that was reimplementing form validation code available on the backend in a way that potentially hid errors (Backend form validation is a must since we do mimetype checking with libmagic to make sure we only allow files we care about) 2) finishing the originally intended attachments app design meaning that some housekeeping is needed to be done once an attachment is stored, e.g. creating a relation between the document and the attachment so we know which attachment is used in which document (which wasn't done before the refactor) Both reasons meant basically being more elaborate in how the attachment form data is handled on the server side to accurately represent the files we have on the filesystem with the data we have in the database, and then redirecting to the document editing URL on success to load the newest state from the database or show a form error page in case of a validation failure and consecutively allowing to fix the form data. I'm sure this feature could be added by bridging the gap between the Django form validation code and the JavaScript client (e.g. using parsley.js: https://pypi.python.org/pypi/django-parsley) but that was out of scope of the attachments refactor given its brokenness.
Comment 2•4 years ago
|
||
MDN Web Docs' bug reporting has now moved to GitHub. From now on, please file content bugs at https://github.com/mdn/sprints/issues/ and platform bugs at https://github.com/mdn/kuma/issues/.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX
Updated•4 years ago
|
Product: developer.mozilla.org → developer.mozilla.org Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•