108790 - chrome registration behaves wrong on Linux

Status: VERIFIED INVALID

(Core :: Internationalization: Localization, defect)

Description

[Kai Engert [:KaiE:]]

In order to hunt down a bug, hyatt suggested to do a clean build, and look at
the entries in file installed-chrome.txt.

It was expected that this file shows lines with "install" and lines with "select".

The reality is: Not a single line with "select" shows up in this file. We need
to find out why.

Comment 1

[Stephane Saux]

Note that this bug prevents the new Mail & News extension mechanism to be
deployed on Linux.

Comment 2

[David Hyatt]

--> bryner.

Try this out and we can compare notes about how this file looks on Win32 and Linux.

Comment 3

[Brian Ryner (not reading)]

The lines:

skin,install,select,classic/1.0 
locale,install,select,en-US 

are added to installed-chrome.txt by themes/makefile.win and l10n/makefile.win,
but this is not done on linux.  Adding this fixes the problem, but is it a bug
that we need that line for it to work properly?

Comment 4

[David Hyatt]

No.  You've found the bug.  THe Linux build system used to add these lines.  I
don't know why it no longer does.

Comment 5

[Brian Ryner (not reading)]

Well, I checked the cvs log and Linux has never added those lines from the
places windows is doing it now... windows started adding the default theme line
on 8/30/2000 (ben, bug 48205), and it started adding the default locale on
9/7/2000 (ssu, bugscape 2152).  It _looks_ like Mac does the default theme line,
but not the default locale line.  Simon?

Anyway, patch coming up for LInux.

Comment 6

[Brian Ryner (not reading)]

Attachment: patch

Comment 7

[tao]

Comment on attachment 57314 [details] [diff] [review]
patch

>Index: mozilla/l10n/Makefile.in
>===================================================================
>RCS file: /cvsroot/mozilla/l10n/Makefile.in,v

This is a wrong place to add this line. mozilla/l10n
might not be part of the build.

please add it to one of the makefile under xpfe/global.

>retrieving revision 1.6
>diff -u -r1.6 Makefile.in
>--- Makefile.in	2000/06/23 00:52:53	1.6
>+++ Makefile.in	2001/11/10 00:36:32
>@@ -37,3 +37,6 @@
> endif
> 
> include $(topsrcdir)/config/rules.mk
>+
>+install::
>+	echo locale,install,select,en-US >> $(DIST)/bin/chrome/installed-chrome.txt

Comment 8

[Brian Ryner (not reading)]

Then we should move it on windows as well...  but why does this make sense to
put in xpfe/global?

Comment 9

[David Hyatt]

Well, what's really curious is that the chrome registry has code to auto-select
a locale when none is selected, so strictly speaking, the select lines are not
required.  For whatever reason, that auto-selection code must be failing.

Comment 10

[Brian Ryner (not reading)]

Attachment: patch v1.1

Comment 11

[Ben Goodger (use ben at mozilla dot org for email)]

Comment on attachment 57380 [details] [diff] [review]
patch v1.1

r=[e-mail]

Comment 12

[Scott MacGregor]

this bug (even though right now it's linux only) might also tie in to: 109923
which I cc'ed bryner and hyatt on. In that case, the smime overlay on windows
RELEASE builds is not getting brought into the compose window. That's because
the following lines aren't showing up in installed-chrome.txt for release builds:

content,install,url,jar:resource:/chrome/messenger.jar!/content/messenger-smime/
locale,install,url,jar:resource:/chrome/en-US.jar!/locale/en-US/messenger-smime/

they are there on debug builds for windows though. 

Comment 13

[tao]

Why would any component need the "select" line in "installed-chrome.txt" in order
to work? My understanding is that the installer script does not have the capability
of selecting a provider. Since we are not packaging "installed-chrome.txt", the
 "select" line won't appear in a shipping product.

As Hyatt said, ChromeRegister should be smart enough to select a default provider.

Comment 14

[Brian Ryner (not reading)]

Actually, on Unix, we do package installed-chrome.txt (in the browser package).
 Not sure if that's correct or not.

Comment 15

[tao]

Mozilla does have it; but not the commercial client.

Comment 16

[Stephane Saux]

What's the status on this?
The security menus are not showing up on the compose window.

Comment 17

[Chris Waterson]

Attachment: rdf sucks

Wrong namespace in SMIME's contents.rdf file.

Comment 18

[Scott MacGregor]

wow nice catch Chris. Mind if I check that in tonight? I'm not sure where i got
that other name space from.

Comment 19

[Brian Ryner (not reading)]

Comment on attachment 57873 [details] [diff] [review]
rdf sucks

r=bryner

I think we still need the registerChrome stuff in the commercial mail.jst for
this to work right on the nightly.

Comment 20

[Scott MacGregor]

Bug #109923 was for the .jst problems and I checked those in this afternoon. So
that part is already good to go. 

Comment 21

[Scott MacGregor]

Comment on attachment 57873 [details] [diff] [review]
rdf sucks

sr=mscott
I just checked this one line change into the tree.

Comment 22

[Kai Engert [:KaiE:]]

Is this bug resolved? Or should Brian's patch be checked in, too?

Comment 23

[Rui Xu]

Checked with both 2001-12-04 Mozilla and commercial client, couldn't fine a 
single line with "select" shows up in file installed-chrome.txt.

Comment 24

[Brian Ryner (not reading)]

Ok, so the original problem here doesn't turn out to really be a problem (the
invalid namespace was the real culprit).

Comment 25

[Rui Xu]

Verified.