553479 - Download progress XBL binding doesn't support unknown sizes

Status: VERIFIED FIXED

(Toolkit :: Add-ons Manager, defect)

Description

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Download progress XBL binding doesn't support unknown sizes. When a file-size is unknown, the progressmeter should be set to undetermined mode.

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Is that a general widget issue?

Comment 2

[Blair McBride [:Unfocused] (UNAVAILABLE)]

(In reply to comment #1)
> Is that a general widget issue?

No, specific to the custom binding (download-progress in extensions.xml) that shows the progress bar and status text.

Comment 3

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Also, should be able to automate testing on this.

Comment 4

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Seems this was fixed awhile ago.

http://hg.mozilla.org/projects/addonsmgr/rev/57f34bdf1358

Comment 5

[Dave Townsend [:mossop]]

Landed on trunk as a part of bug 554007

Comment 6

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Any chance to get this manually tested for verification? We always send the extension size on AMO, right?

Comment 7

[Blair McBride [:Unfocused] (UNAVAILABLE)]

(In reply to comment #6)
We always send the extension size on AMO, right?

As far as I know, yea. To test, you need a server that won't send the size in the HTTP headers (also doable via a server-side script).

Comment 8

[Henrik Skupin [:whimboo][⌚️UTC+1]]

General implementation works, even the binding is broken on OS X. See bug 616643.

Talked with Blair on IRC and as it turns out a manual test would be necessary because there seems to be no way to let httpd server content without a content length. Dave, or would that be possible?

Verified fixed with Mozilla/5.0 (Windows NT 5.1; rv:2.0b8pre) Gecko/20101203 Firefox/4.0b8pre by testing: http://mozilla.hskupin.info/aom/undetermined/

Comment 9

[Dave Townsend [:mossop]]

(In reply to comment #8)
> General implementation works, even the binding is broken on OS X. See bug
> 616643.
> 
> Talked with Blair on IRC and as it turns out a manual test would be necessary
> because there seems to be no way to let httpd server content without a content
> length. Dave, or would that be possible?

Should be possible, a server side script like php ought to be about to output content with no content length header.

Comment 10

[Blair McBride [:Unfocused] (UNAVAILABLE)]

(In reply to comment #9)
> Should be possible, a server side script like php ought to be about to output
> content with no content length header.

Yea, that's what he did (the the URL in comment 8) - when he says "httpd" there, he really means httpd.js in mochitest (which I know very little about).

Comment 11

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Ok, so testing the undetermined mode should be possible with httpd.js. As given by Jeff we would have to do the following:

but if you *only* want to disable content-length, you should seizePower() and write exactly the bytes you want, so as not to rely on the mechanics of content-length provision

Comment 12

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Would be great to get an automated test for it. In the meantime we will have a manual one. The extension provided in the url will show an undetermined progress meter.

Comment 13

[Henrik Skupin [:whimboo][⌚️UTC+1]]

As addition, for the Litmus test we have to check that the undetermined progress meter is used and the start and end caps are displayed correctly.

Comment 14

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Talked with Blair on IRC and we agreed on that it is not worth a test. Everything here is nearly CSS and it will take us a lot of time to create a test in either case, manual or automated.