Download progress widget doesn't update its progress meter

VERIFIED FIXED in mozilla2.0b7

Status

()

Toolkit
Add-ons Manager
VERIFIED FIXED
8 years ago
8 years ago

People

(Reporter: whimboo, Assigned: mossop)

Tracking

Trunk
mozilla2.0b7
All
Mac OS X
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite -
in-litmus -

Firefox Tracking Flags

(blocking2.0 final+)

Details

(Whiteboard: [AddonsRewrite])

Attachments

(1 attachment)

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
(Assignee)

Updated

8 years ago
blocking2.0: ? → final+
(Assignee)

Updated

8 years ago
Assignee: nobody → bmcbride
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]
(Assignee)

Comment 4

8 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

8 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.
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.
(Assignee)

Updated

8 years ago
Whiteboard: [AddonsRewrite] → [AddonsRewrite][good first bug]
(Assignee)

Comment 10

8 years ago
Created attachment 479184 [details] [diff] [review]
patch rev 1

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)
(Assignee)

Updated

8 years ago
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+
(Assignee)

Updated

8 years ago
Whiteboard: [AddonsRewrite][has patch][needs review Unfocused] → [AddonsRewrite][has patch][needs-checkin-post-b7]
(Assignee)

Comment 12

8 years ago
Fixed: http://hg.mozilla.org/mozilla-central/rev/1d9300a951b7
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Flags: in-testsuite-
Flags: in-litmus-
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

Updated

8 years ago
Target Milestone: mozilla2.0b8 → mozilla2.0b7
You need to log in before you can comment on or make changes to this bug.