Closed
Bug 566605
Opened 15 years ago
Closed 14 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•15 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•15 years ago
|
blocking2.0: ? → final+
Assignee | ||
Updated•15 years ago
|
Assignee: nobody → bmcbride
Comment 2•15 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•15 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•15 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•15 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•15 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•15 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•15 years ago
|
||
This is OS X only. Works fine on Windows and Linux.
OS: All → Mac OS X
Comment 9•15 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•14 years ago
|
Whiteboard: [AddonsRewrite] → [AddonsRewrite][good first bug]
Assignee | ||
Comment 10•14 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•14 years ago
|
Whiteboard: [AddonsRewrite][good first bug] → [AddonsRewrite][has patch][needs review Unfocused]
Comment 11•14 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•14 years ago
|
Whiteboard: [AddonsRewrite][has patch][needs review Unfocused] → [AddonsRewrite][has patch][needs-checkin-post-b7]
Assignee | ||
Comment 12•14 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 14 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•14 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•14 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
•