[MGNLUI-868] Upload file component: clicking on dialog's cancel button should interrupt upload in progress. Created: 10/Sep/12  Updated: 14/Jun/13  Resolved: 11/Jun/13

Status: Closed
Project: Magnolia UI
Component/s: dialogs
Affects Version/s: None
Fix Version/s: 5.0

Type: Bug Priority: Blocker
Reporter: Federico Grilli Assignee: Aleksandr Pchelintcev
Resolution: Fixed Votes: 0
Labels: dialog
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:
Sprint: RC 1

 Description   

Currently canceling an upload in progress only works when clicking on the cancel icon right of the progress bar. The same thing should happen if a user decides to click on the dialog's cancel button while an upload is in progress. Atm, the upload keeps on going in the background and trying to reopen the dialog will issue an out of synch exception by Vaadin.

This only happen with the drag and drop by clicking to the dialog cancel button.



 Comments   
Comment by Eric Hechinger [ 18/Sep/12 ]

by overriding the detach() in AbstractUploadFileField make the job (works fine, Upload is canceled, every thing is fine after this)... except that for a cancelled drag and drop file, we got a null pointer stack trace.

SEVERE: Terminal error:
java.lang.NullPointerException
at com.vaadin.terminal.gwt.server.CommunicationManager.cleanStreamVariable(CommunicationManager.java:420)
at com.vaadin.terminal.gwt.server.AbstractCommunicationManager.doHandleXhrFilePost(AbstractCommunicationManager.java:523)
at com.vaadin.terminal.gwt.server.CommunicationManager.handleFileUpload(CommunicationManager.java:265)
at com.vaadin.terminal.gwt.server.AbstractApplicationServlet.service(AbstractApplicationServlet.java:495)
at info.magnolia.ui.vaadin.integration.servlet.MagnoliaIcePushServlet.service(MagnoliaIcePushServlet.java:111)
at info.magnolia.ui.vaadin.integration.servlet.MultipleBrowserWindowsApplicationServlet.service(MultipleBrowserWindowsApplicationServlet.java:136)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at info.magnolia.cms.filters.ServletDispatchingFilter.doFilter(ServletDispatchingFilter.java:123)

In fact, in CommunicationManager.class,
@Override
protected void cleanStreamVariable(VariableOwner owner, String name) {
Map<String, StreamVariable> nameToStreamVar = pidToNameToStreamVariable
.get(getPaintableId((Paintable) owner));
nameToStreamVar.remove("name");

pidToNameToStreamVariable do not contain anymore owner --> nameToStreamVar = null --> nameToStreamVar.remove("name") --> null pointer exception.

Issue is that pidToNameToStreamVariable was containing the DropZone, but some process removed it from pidToNameToStreamVariable by calling:
@Override
protected void unregisterPaintable(Component p)

I was not able to identify the process that removed the drop zone from pidToNameToStreamVariable before cleanStreamVariable is called.

Generated at Mon Feb 12 08:41:05 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.