307225 - Language packs for Firefox 1.5 Beta need chrome.manifest files in order to install

Status: RESOLVED FIXED

(Core :: Internationalization: Localization, defect)

Description

[Teune van Steeg]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050905 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050905 Firefox/1.0+

Currently language packs won't install in recent 1.0+ branch builds, because of
a failed chrome registration. This is because the language packs don't contain
contents.rdf files anymore. 

When I manually add a chrome.manifest file based on the install.rdf file (and
raise the em maxVersion to 1.0+), the language packs install without any problem.

Further more, according to the install.rdf specs at
http://www.mozilla.org/projects/firefox/extensions/packaging/extensions.html an
em:type entry has to be specified in the install.rdf file (type=8 for
localizations), but I don't think leaving that out will not install the language
pack

Reproducible: Always

Steps to Reproduce:
1. download language pack from given url
2. manually raise the maxVersion to 1.0+ in install.rdf so it will install in
recent 1.0+ nightly
3. drag and drop modified xpi in browser, so it will install
4. restart Firefox 
5. Notice chrome registration failed error

Actual Results:  
Language pack will not install with error dialog saying that chrome registration
failed

Expected Results:  
chrome registration should be succesfull

When a chrome.manifest file is added to the language pack, the em:file
information in install.rdf could be removed, because that is not necessary anymore.

BTW: I use the language packs to test localizations of my extensions, so I don't
have to download several different localized builds.

Comment 1

[Teune van Steeg]

Attachment: chrome.manifest file I created for fr (french) language pack

With this chrome.manifest file added to the French (fr) language pack, and a
modified install.rdf (which I will attach next), the language pack installed
without a problem

Comment 2

[Teune van Steeg]

Attachment: modified install.rdf for fr (French) language pack

In this file I commented out the em:file declaration, because with a
chrome.manifest file this is not necessary anymore.

I also added this line <em:type>8</em:type> to show it is a localization.

And I raised the maxVersion to 1.4 (so it will work when the version of Firefox
is raised to 1.4). Apart from the last step, these modifications are not
necessary to install the language pack correctly in the latest
mozilla1.8-branch Firefox nightly

Comment 3

[Teune van Steeg]

changing from Product: Mozilla Localizations, Component: Other to Product: Core,
Component: Localization, because I think it's better off here.

And asking blocking 1.8b5, as I think this should be fixed before Firefox 1.5
comes out and I can't ask for blocking-aviary1.5 here.

Comment 4

[Axel Hecht [:Pike]]

I'll be driving this, patch coming up. It'd be good to have this on the branch,
too.
This is merely l10n language packaging build foo, so no l10n impact per-se.

Comment 5

[Axel Hecht [:Pike]]

CCing localizers, though there is no l10n impact codewise, this is still 
interesting.

Comment 6

[Axel Hecht [:Pike]]

Attachment: fix language pack building

This patch does the following fixes to the generic install.rdf:
It removes the obsolete em:file stuff, add em:type and uses @MOZ_APP_VERSION@
for
em:minVersion and maxVersion, as the build is checking for compatibility
anyway.

In addition, I added a USE_EXTENSION_MANIFEST=1 to the phase that builds the
langpacks, so that chrome.manifest is generated (it looks like the one
attached),
and pack that generated file, those are the changes to Makefile.in.

Comment 7

[Zibi Braniecki [:zbraniecki][:gandalf]]

Comment on attachment 196307 [details] [diff] [review]
fix language pack building

r+

Comment 8

[Axel Hecht [:Pike]]

fix landed on the trunk, letting it smoke for a bit.

Comment 9

[Axel Hecht [:Pike]]

Backed out the Makefile.in part, as that busted macs.

I'd be thankful if someone could run make -n with the modified makefile and 
compare that to http://www.math.hu-berlin.de/~hecht/build.log, as that
does give -c l10n-source, which the macs complain about.

http://tinderbox.mozilla.org/showlog.cgi?log=Mozilla-l10n-da/1126875840.20470.gz
is an example build log of the bustage (not special to da, other builds at
the time are busted the same way).

Comment 10

[Asa Dotzler [:asa]]

Axel, we need to get this in the branch ASAP. Is it ready to go?

Comment 11

[Axel Hecht [:Pike]]

macs refused to give a profound reason for the error message so far, I'll provide
a patch that just disables the chrome.manifest building for the mac, unless
bsmedberg has a cycle to investigate. I looked at a log of make -n, and even on
a mac, the locale dir argument is given. May be escaping or file path fun or
whatever, I'll need a mac to do some perl -d.

Anyway, if the locale xpis built on mac don't make nice langpacks, that's not too
bad.

Comment 12

[Axel Hecht [:Pike]]

*** Bug 309716 has been marked as a duplicate of this bug. ***

Comment 13

[Axel Hecht [:Pike]]

Attachment: build and ship chrome.manifest for all but macs

I want benjamin to review this, this is his baby and I hack it.

Comment 14

[Alex Ihrig [:Thunderbird_Mail_DE]]

Not sure, if it is related to this bug:

<maxversion> is still set to 1.1 in latest langpacks.

This should be the coresponding version (1.4 at this time) to the relating binaries.

Comment 15

[Benjamin Smedberg]

Comment on attachment 197170 [details] [diff] [review]
build and ship chrome.manifest for all but macs

Well, that's more than a little weird, and it should probably be investigated.
But the hack-solution ought to be to ifdef
http://lxr.mozilla.org/mozilla/source/browser/locales/Makefile.in#252 so that
we don't try to make the langpack at all on mac.

Comment 16

[Axel Hecht [:Pike]]

Re #14, this bug isn't fixed for mail at all, 
http://lxr.mozilla.org/mozilla/source/mail/locales/generic/install.rdf.

Benjamin, I need someone with a mac and perl debugger time to solve this right
for 1.5.
Hacking the langpack out of there is more intrusive than justified, IMHO,
as we call the libs phase there. I do expect to have a mac at my disposal post
1.5, too, and I plan to pick this up then.

As we're talking, I would like to set max and minor version of the langpack to
the branch base version and the branch head version, respectively. Something
equivalent to 1.0 and 1.0.7. Any idea for that?

Comment 17

[Benjamin Smedberg]

Attachment: Process the "-e" option to make-jars.pl correctly [checked in on 1.8 branch]

Comment 18

[Benjamin Smedberg]

Attachment 197705 [details] [diff] checked in on trunk.

Comment 19

[Mike Schroepfer]

Comment on attachment 197705 [details] [diff] [review]
Process the "-e" option to make-jars.pl correctly [checked in on 1.8 branch]

Approved for 1.8b5.

Comment 20

[Axel Hecht [:Pike]]

Relanded the backed out part of attachement 196307, thanks to bsmedberg for 
finding the bug in make-js.pl.

Leaving open for the mail part of this.

Comment 21

[Axel Hecht [:Pike]]

Comment on attachment 196307 [details] [diff] [review]
fix language pack building

Requesting approval, this is a l10n langpack-only change that does not require
interaction from l10n owners.

Now that the trunk and the branch have the required fix, this is low risk.

Comment 22

[Asa Dotzler [:asa]]

Comment on attachment 196307 [details] [diff] [review]
fix language pack building

do we need to make these same changes to Thunderbird? If so, can we get a patch
here or in a new bug please? thanks.

Comment 23

[Axel Hecht [:Pike]]

Attachment: ... same fix for mail

Comment 24

[Axel Hecht [:Pike]]

Fixed for both thunderbird and firefox on both trunk and 1.5 branch.