Looks like what's happening is the "Delete" button in the UI is calling the transfer indicator's cancel() method for that transfer, which indicator-transfer passes along to com.canonical.applications.Download's cancel() method.
When Indicator-transfer hears a 'canceled' state change from download-manager, it flags that transfer as canceled in its internal model and this is reflected in the model exported to unity. However the UI has unconditionally removed the menuitem when "Delete" was pressed, so the model and ui are out of sync here and that's a unity8 issue.
On the other hand, even if things stayed in sync I don't think that would be a good solution here. When you press "Delete" you don't *want* the transfer to reappear in the "resume" section... you want it deleted, gone. Otherwise to actually get rid of it you'd have to delete it /twice/, once from the active section and then once from the resume section.
Looks like what's happening is the "Delete" button in the UI is calling the transfer indicator's cancel() method for that transfer, which indicator-transfer passes along to com.canonical. applications. Download' s cancel() method.
When Indicator-transfer hears a 'canceled' state change from download-manager, it flags that transfer as canceled in its internal model and this is reflected in the model exported to unity. However the UI has unconditionally removed the menuitem when "Delete" was pressed, so the model and ui are out of sync here and that's a unity8 issue.
On the other hand, even if things stayed in sync I don't think that would be a good solution here. When you press "Delete" you don't *want* the transfer to reappear in the "resume" section... you want it deleted, gone. Otherwise to actually get rid of it you'd have to delete it /twice/, once from the active section and then once from the resume section.