Closed
Bug 566605
Opened 14 years ago
Closed 13 years ago
Download progress widget doesn't update its progress meter
Categories
(Toolkit :: Add-ons Manager, defect)
Tracking
()
VERIFIED
FIXED
mozilla2.0b7
Tracking | Status | |
---|---|---|
blocking2.0 | --- | final+ |
People
(Reporter: whimboo, Assigned: mossop)
References
Details
(Whiteboard: [AddonsRewrite])
Attachments
(1 file)
823 bytes,
patch
|
Unfocused
:
review+
|
Details | Diff | Splinter Review |
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a5pre) Gecko/20100517 Minefield/3.7a5pre (.NET CLR 3.5.30729) ID:20100517035949 If you install a locally saved XPI via D&D to the Addons Manager, the download progress widget will display 0% done when the installation dialog comes up. But at this stage it should display 100%. Steps: 1. Download a XPI file 2. Use D&D to install that extension
Reporter | ||
Comment 1•14 years ago
|
||
That doesn't only happen for locally stored XPI's. Even for add-ons which get downloaded from websites the progress meter will not update. It only shows 0% and once the extension has been downloaded to right end gets a blue background. But the middle part stays gray.
blocking2.0: --- → ?
Summary: Download progress widget shows 0% done when installing a locally saved XPI → Download progress widget doesn't update its progress meter
Assignee | ||
Updated•14 years ago
|
blocking2.0: ? → final+
Assignee | ||
Updated•13 years ago
|
Assignee: nobody → bmcbride
Comment 2•13 years ago
|
||
Hm, that sounds like a regression - that used to work for downloaded extensions. Think it was always broken for local files though.
Reporter | ||
Comment 3•13 years ago
|
||
Well, I think it's a layering issue here. We simply do not re-draw the area in the middle of the button. Is that a theme or a widget issue? We should probably move it to the correct component then.
Whiteboard: [rewrite] → [AddonsRewrite]
Assignee | ||
Comment 4•13 years ago
|
||
(In reply to comment #3) > Well, I think it's a layering issue here. We simply do not re-draw the area in > the middle of the button. Is that a theme or a widget issue? We should probably > move it to the correct component then. What makes you think that?
Assignee | ||
Comment 5•13 years ago
|
||
The problem here looks to be that the progress meter is only updated whenever an onDownloadProgress event is received. But for local XPI's and if you open the add-ons manager after the download is finished no onDownloadProgress event will ever be sent, the progress is already 100%. The constructor probably needs to default the progress bar appropriately in these cases.
Reporter | ||
Comment 6•13 years ago
|
||
Well, when you watch the installation you will see that the start and end cap have the progress animation but in-between it's not shown. Looks like that something is positioned above the progress meter (between both ends) with a non-transparent background.
Reporter | ||
Comment 7•13 years ago
|
||
I have never really tried to reproduce this bug on Windows. As it turns out it works when installing add-ons from the Search pane. Only on OS X the progress bar isn't updated. Could this be a simply theme issue?
Reporter | ||
Comment 8•13 years ago
|
||
This is OS X only. Works fine on Windows and Linux.
OS: All → Mac OS X
Comment 9•13 years ago
|
||
(In reply to comment #8) > This is OS X only. Works fine on Windows and Linux. Ok, that makes more sense. Also, the issue described in comment 5 is really a separate bug.
Assignee | ||
Updated•13 years ago
|
Whiteboard: [AddonsRewrite] → [AddonsRewrite][good first bug]
Assignee | ||
Comment 10•13 years ago
|
||
Progress meters on OSX normally use a custom binding with basically no content, allowing the OS to actually paint the progress. This switches it back.
Assignee | ||
Updated•13 years ago
|
Whiteboard: [AddonsRewrite][good first bug] → [AddonsRewrite][has patch][needs review Unfocused]
Comment 11•13 years ago
|
||
Comment on attachment 479184 [details] [diff] [review] patch rev 1 (In reply to comment #10) > Progress meters on OSX normally use a custom binding with basically no content, > allowing the OS to actually paint the progress. This switches it back. This was confusing... to clarify: this switches it back to the *non custom* binding that other OSes use. We probably want a comment in there, explaining why this hack-foo is needed.
Attachment #479184 -
Flags: review?(bmcbride) → review+
Assignee | ||
Updated•13 years ago
|
Whiteboard: [AddonsRewrite][has patch][needs review Unfocused] → [AddonsRewrite][has patch][needs-checkin-post-b7]
Assignee | ||
Comment 12•13 years ago
|
||
Fixed: http://hg.mozilla.org/mozilla-central/rev/1d9300a951b7
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Flags: in-testsuite-
Flags: in-litmus-
Resolution: --- → FIXED
Whiteboard: [AddonsRewrite][has patch][needs-checkin-post-b7] → [AddonsRewrite]
Target Milestone: --- → mozilla2.0b8
Reporter | ||
Comment 13•13 years ago
|
||
Verified fixed with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b8pre) Gecko/20101023 Firefox/4.0b8pre
Status: RESOLVED → VERIFIED
Updated•13 years ago
|
Target Milestone: mozilla2.0b8 → mozilla2.0b7
You need to log in
before you can comment on or make changes to this bug.
Description
•