Closed Bug 1290772 Opened 4 years ago Closed 4 years ago

Langpacks in are wrongly served as "application/zip" instead of "application/x-xpinstall"


(Release Engineering :: Release Automation: Other, defect)

Not set


(firefox51 fixed)

Tracking Status
firefox51 --- fixed


(Reporter: nohamelin, Assigned: rail)




(1 file)

Browse to:

...and then click in some of the available language packs.

What happened?
The language pack is downloaded, or open with the default external application, whatever action is set in the browser settings.

What should have happened?
The add-on installation doorhanger is triggered, starting the installation, or showing the notification that the language pack is not compatible, depending of the browser version.

I'm seeing this wrong behaviour since some time ago, but only for some directories; for example: ok, serving the language packs for Nightly as application/x-xpinstall;
but it's not working as expected for directories containing current release and ESR langpacks. Now they are downloaded and then installed via "Install add-on from file..." from the gear button of the Add-ons Manager.
Component: General Automation → Operations: Product Delivery
Product: Release Engineering → Cloud Services
QA Contact: catlee → oremj
Are these uploaded directly to s3 or via post_upload?
Assignee: nobody → oremj
Flags: needinfo?(rail)
These are direct uploads, doh. Moving to Releng.
Component: Operations: Product Delivery → Release Automation
Flags: needinfo?(rail)
Product: Cloud Services → Release Engineering
QA Contact: oremj → rail
Assignee: oremj → rail
Comment on attachment 8779349 [details]
Bug 1290772 - Set proper MIME type for XPIs  DONTBUILD
Attachment #8779349 - Flags: review?(bugspam.Callek) → review+
Pushed by
Set proper MIME type for XPIs r=Callek r=release DONTBUILD
Closed: 4 years ago
Resolution: --- → FIXED
Depends on: 1336754
You need to log in before you can comment on or make changes to this bug.