Closed
Bug 623192
Opened 14 years ago
Closed 14 years ago
Restarting download of add-on completely removes progress notification
Categories
(Toolkit :: Add-ons Manager, defect)
Toolkit
Add-ons Manager
Tracking
()
VERIFIED
FIXED
mozilla2.0b9
Tracking | Status | |
---|---|---|
blocking2.0 | --- | final+ |
People
(Reporter: whimboo, Assigned: mossop)
References
()
Details
Attachments
(1 file)
6.21 KB,
patch
|
Gavin
:
review+
|
Details | Diff | Splinter Review |
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b9pre) Gecko/20110104 Firefox/4.0b9pre ID:20110104030354
With the landing of the patch on bug 570012, we now have the doorhanger notification which informs about the current download state of an add-on. There is a button which can be used to cancel the download. Right after another notification comes up, which let you restart the download. It works mostly once, but repeating the step multiple times, completely removes the download progress notification.
Steps:
1. Search for a large add-on like: Cooliris
2. Install the add-on
3. While downloading click the x button to cancel the download
4. Click on "Restart Download"
5. Repeat steps 3 and 4
On Windows it always fails for me for the second try, on OS X the notification even gets removed for the first restart.
Reporter | ||
Updated•14 years ago
|
blocking2.0: --- → ?
Assignee | ||
Comment 1•14 years ago
|
||
This definitely worked when I last tested the patch, and we even have automated tests that are meant to be running this case so not sure what is going on.
The install does complete though so it's possible we may end up unblocking it later, for now though it looks pretty silly so lets block on it.
Assignee: nobody → dtownsend
blocking2.0: ? → final+
Assignee | ||
Updated•14 years ago
|
Whiteboard: [waiting on try]
Assignee | ||
Comment 2•14 years ago
|
||
This got introduced by over-zealous leak avoidance. If while the notification is open it gets recreated (either by hiding and showing the panel, a new notification being added or another removed) then the references to the source content window get cleaned up too soon. I'm not positive why this would happen differently on different platforms, but focus changes affect it which I think was why the test saw it as working when it wasn't.
This makes us clean up the references when the notification is finally removed and also makes the test force a rebuild by hiding and showing the notification.
Attachment #501693 -
Flags: review?(gavin.sharp)
Assignee | ||
Updated•14 years ago
|
Status: NEW → ASSIGNED
Whiteboard: [waiting on try] → [has patch][needs review gavin]
Updated•14 years ago
|
Attachment #501693 -
Flags: review?(gavin.sharp) → review+
Assignee | ||
Updated•14 years ago
|
Whiteboard: [has patch][needs review gavin] → [has patch]
Assignee | ||
Comment 3•14 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Flags: in-testsuite+
Flags: in-litmus-
Resolution: --- → FIXED
Whiteboard: [has patch]
Target Milestone: --- → mozilla2.0b9
Reporter | ||
Comment 4•14 years ago
|
||
Verified fixed with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b9pre) Gecko/20110109 Firefox/4.0b9pre ID:20110109030350
Status: RESOLVED → VERIFIED
Updated•14 years ago
|
You need to log in
before you can comment on or make changes to this bug.
Description
•