Show something relevant than "4.0GB" when server doesn't send xpi size to Firefox

NEW
Unassigned

Status

Core Graveyard
Installer: XPInstall Engine
10 years ago
2 years ago

People

(Reporter: Louise, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

10 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b4pre) Gecko/2008021204 Minefield/3.0b4pre
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b4pre) Gecko/2008021204 Minefield/3.0b4pre

The file size shown when installing new extension does not show the actual file size.

Reproducible: Always

Steps to Reproduce:
1.Go to the above URL
2.Install SearchWP 2.0b3
3.
Actual Results:  
the file size shown under the progress meter tells it is 4.0 GB

Expected Results:  
show the correct file size


When saved on disk, Donload Manager says it is 46.2 KB. In Finder, the file size on disk is 48 KB.
(Reporter)

Updated

10 years ago
Version: unspecified → Trunk
Server is sending no length for the xpi so there isn't a way for us to know how big it is. Looks like the xpinstallmanager sees -1 as a length which then get's cast to an unsigned value for passing through nsIXPIProgressDialog::OnProgress
Component: Extension/Theme Manager → Installer: XPInstall Engine
Product: Firefox → Core
QA Contact: extension.manager → xpi-engine
Version: Trunk → unspecified
(Reporter)

Comment 2

10 years ago
I guess most people just dowonload extensions from AMO so this might not be so important.
But maybe writing something like "Unknown" instead of 4.0 GB would be nice..
(Reporter)

Comment 3

10 years ago
Show something relevant than "4.0GB" when server doesn't send xpi size to Firefox
Summary: File Size description in Extension/Theme Manager is wrong when installing Extension/Add-on → Show something relevant than "4.0GB" when server doesn't send xpi size to Firefox
Version: unspecified → Trunk

Updated

10 years ago
Duplicate of this bug: 420983

Updated

10 years ago
Status: UNCONFIRMED → NEW
Component: Installer: XPInstall Engine → Extension/Theme Manager
Ever confirmed: true
OS: Mac OS X → All
Product: Core → Firefox
QA Contact: xpi-engine → extension.manager
Hardware: Macintosh → All

Comment 5

10 years ago
Hrm, as filed this looked more like a front-end bug. In case this can actually be fixed in the back-end: sorry, Dave.
The bug is due to the xpinstall interfaces trying to pass a negative value as an unsigned value. This would have to be changed in xpinstall for use to be able to see from the frontend that the size was unknown. This is an xpinstall issue.
Component: Extension/Theme Manager → Installer: XPInstall Engine
Product: Firefox → Core
QA Contact: extension.manager → xpi-engine

Comment 7

8 years ago
How does a server pass this length?
(In reply to comment #7)
> How does a server pass this length?

The value comes from the Content-Length header

Comment 9

8 years ago
This bug is still present in still present in 3.6.6. Apache is sending the correct content-length, but FireFox is still displaying it as 4GB.

matt:~ matt$ curl -I www.notableapp.com/toolbuttons/notable1.0.16.xpi
HTTP/1.1 200 OK
Date: Mon, 19 Jul 2010 21:19:22 GMT
Server: Apache/2.2.3 (Red Hat)
Last-Modified: Fri, 25 Jun 2010 21:28:27 GMT
ETag: "14bc7-489e1739a94c0"
Accept-Ranges: bytes
Content-Length: 84935
Vary: Accept-Encoding
Connection: close
Content-Type: application/x-xpinstall

The headers sent from mozilla.org look almost identical. What header or information do we need out webserver to return so that Firefox displays the size correctly?
matt:~ matt$ curl -I http://releases.mozilla.org/pub/mozilla.org/addons/8879/foxtab-1.3-fx.xpi
HTTP/1.1 200 OK
Date: Mon, 19 Jul 2010 21:26:23 GMT
Server: Apache
Last-Modified: Fri, 22 Jan 2010 16:41:24 GMT
ETag: "dec3c-82cc0-47dc37d78b500"
Accept-Ranges: bytes
Content-Length: 535744
Content-Type: application/x-xpinstall
(Assignee)

Updated

2 years ago
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.