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
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
Hm, that sounds like a regression - that used to work for downloaded extensions. Think it was always broken for local files though.
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]
(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?
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.
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.
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?
This is OS X only. Works fine on Windows and Linux.
OS: All → Mac OS X
(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.
Whiteboard: [AddonsRewrite] → [AddonsRewrite][good first bug]
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: bmcbride → dtownsend
Status: NEW → ASSIGNED
Attachment #479184 - Flags: review?(bmcbride)
Whiteboard: [AddonsRewrite][good first bug] → [AddonsRewrite][has patch][needs review Unfocused]
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+
Whiteboard: [AddonsRewrite][has patch][needs review Unfocused] → [AddonsRewrite][has patch][needs-checkin-post-b7]
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Whiteboard: [AddonsRewrite][has patch][needs-checkin-post-b7] → [AddonsRewrite]
Target Milestone: --- → mozilla2.0b8
Verified fixed with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b8pre) Gecko/20101023 Firefox/4.0b8pre
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.