Install scripts cannot select chrome

NEW
Unassigned

Status

Core Graveyard
Installer: XPInstall Engine
P1
major
17 years ago
2 years ago

People

(Reporter: dveditz, Unassigned)

Tracking

Trunk
mozilla1.3alpha
All
Other
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [xpiprd])

Attachments

(1 attachment)

(Reporter)

Description

17 years ago
Install must be able to select chrome. without it when you install locales or 
skins they do not update the user-<chrome>.rdf files in the bin/chrome 
directory. This leads to a couple of major problems:

First, if you install an add-on component with a private skin then the 
component will not work -- period. The user will have to know how to edit the 
user-skins.rdf file manually. This is tempting certain developers to use the 
install to overwrite the existing user-skins.rdf file, which will certainly 
make their component work, but will break anything else registered there. Given 
more than one such component we would end up in an install-war.

Second, on the initial Mozilla/Netscape 6 install without a way to select skin 
and locale during the install then the user-<chrome>.rdf files will be updated 
as components are used, which on a locked-down system (e.g. Unix or corporate 
WinNT) cannot be done after the first run, leading to failure.
(Reporter)

Updated

17 years ago
Blocks: 41057
Status: NEW → ASSIGNED
Keywords: rtm
Whiteboard: [rtm+]
Target Milestone: --- → mozilla0.6

Comment 1

17 years ago
Ccing David.

Comment 2

17 years ago
You can force a selection using installed-chrome.txt.  Is that not good enough? 
 Also, the chrome registry will auto-select for you if nothing is selected, but 
it tries to do this only for the install dir (which is bad, since you may not 
have write access to the install dir).

Comment 3

17 years ago
I have a temp work around which works ok.
After xpi installs the package, i have an install.xul file which is a simple
dialog which calls "selectSkinForPackage" and does the right thing for the
package. 

The only problem is the user has to do this:

./mozilla -chrome chrome://my_package/content/install.xul

This is a lot to ask an end user to do . . .

--pete

Comment 4

17 years ago
>You can force a selection using installed-chrome.txt.  Is that not good enough?

How . . . ?

(Reporter)

Comment 5

17 years ago
How do we know what to put in installed-chrome.txt? Updating the summary to 
indicate this is a deficiency in the install command set, not that we're 
lacking any chrome registry functionality.  We don't want add-on components to 
solve this problem by overwriting installed-chrome.txt themselves, that just 
leads to an install war.
Summary: Install cannot select chrome → Install scripts cannot select chrome

Comment 6

17 years ago
Yes, absolutely.  We should give people the capability to install and select 
right off the bat.  Make sure you give the capability to do the selection in the 
profile dir, since we won't want to be writing to the install dir.

Comment 7

17 years ago
Dan Dave. I have an idea that is a resonable solution i think.

How about for now making package authors responsable for including and
install.xul file. I have tested this method out all morning and it works great!

If there was a way to make a call to call "window.openDialog" at the end of the
install all of our problems will be solved.

I can call this dialog after the install happens the user presses the finish
button, the skin path is registered w/ selectSkinForPackage and the app then
launches. 

Clean and easy.

If you guys accept this method then we are already done.
You can test out what i am talking about here:

http://aphrodite.mozdev.org/installation.html

or here:

http://chameleon.mozdev.org/installation.html

It is actually pretty cool.

Dan, can we open a window from install.js w/out compromising "thread safety" ??

--pete


Comment 8

17 years ago
Pete, since this dialog would presumably be the same for all packages, it seems 
like we should automatically display the appropriate dialog for selection on our 
own.

Comment 9

17 years ago
Well the only reason i was suggesting that the authors do it themselves is
because i have a real cool image of a chameleon as the background of my dialog.
It just looks *SO COOL* man!

;-)

--pete

Comment 10

17 years ago
There is a discussion, "UI language switching", about selecting the initial
 default locale in an intranet deployment environment. Please read
news://news.mozilla.org/netscape.public.mozilla.i18n for details.

Comment 11

17 years ago
Created attachment 15963 [details]
Cool Dialog!

Comment 12

17 years ago
Dan, one note on install wars. I have been wiping installed-chrome.txt away with
the different packages i'm workin on and have not had any probs.

I tried *not* using installed-chrome.txt but it doesn't work w/out it . . .


It seems that this file is only needed once for initialization of the package.

Is this correct?

Thanks

--pete
(Reporter)

Comment 13

17 years ago
The installed-chrome.txt is only needed once, but it's not processed until next 
start up. By "install wars" I meant that if you happened to install more than 
one package in the same session that used this technique they would stomp on 
each other, and the one installed first would not get registered/selected 
correctly.

Comment 14

17 years ago
PDT marking [rtm-]. It's not clear why Seamonkey needs this before we ship. If
skins work for our shipping components, we're done. Please renominate if we've
misunderstood.
Whiteboard: [rtm+] → [rtm-]
(Reporter)

Comment 15

17 years ago
Appealing PDT decision: they don't work, at least not well. 

With the select line put in installed-chrome.txt (which this fix would do) the 
right stuff gets written to user-skins.rdf at first start-up (and 
user-locales.rdf -- locales have the same problem). Without it nothing gets 
written until that component is used, which has been leaving mail and aim 
without a skin or locale if installed on a system that locks down the installed 
directory (as is common on unix, less common but not rare on windows NT).

The workaround would be to leave the install directory world writable, or 
hand-hack an installed-chrome.txt
Whiteboard: [rtm-] → [rtm+]

Comment 16

17 years ago
I need this for Netscape's Theme Builder FWIW. 

This certianly is a problem and quite frankly is half/assed the way it is
implemented right now.

--pete


Comment 17

17 years ago
Dan, this seems to point out a profile related problem.  We shouldn't have to
hack stuff into the install directory to handle user level choices.  It seems to
me that we're storing this info in the wrong place and shouldn't have
user-<anything>.rdf files anywhere in the install hierarchy.

Can you explain that part of it for me?

Comment 18

17 years ago
Dan, i have stumbled upon an issue w/ installed-chrome.txt.
On unix a carrage return is ^J and on windows it is ^M

It seems that the ^J's are barfing on windows.
How do i deal w/ this issue of platform control chars?

If i edit them out on windows it works fine.

Thanks

--pete
(Reporter)

Comment 19

17 years ago
Steve: The two user-<foo>.rdf files in the global chrome directory are misnamed
IMO; a better choice would be default-skins.rdf and default-locales.rdf since
these contain the selections used when the user hasn't otherwise made a
selection recorded in the profile user-<foo>.rdf files.

Whatever the name, if you install on a unix system or locked-down NT system the
user-<foo>.rdf files generated on the first launch are incomplete.  This leads
to problems with SHIPPING CHROME, this is not some abstract nice to have. See
bug 53674 for one instance, there are similar problems with Mail and AIM.
Blocks: 53674, 53680
Whiteboard: [rtm+] → [rtm+ need patch]

Comment 20

17 years ago
PDT marking [rtm need info]. Please change to [rtm+] when fix has been code
reviewed.
Whiteboard: [rtm+ need patch] → [rtm need info]

Comment 21

17 years ago
I'm working for Japanese language pack. 
Many end users said why langpack doesn't switch default global locale
to ja-JP in xpi installing.

If I add "locale,install,select,ja-JP" into installed-chrome.txt manually,
mozilla use ja-JP for default global locale.
But I don't know how to add this line into installed-chrome.txt automatically.

I'd like the option. Is there the method?

I can add the following line into installed-chrome.txt by 
writing "registerChrome(LOCALE | DELAYED_CHROME, getFolder(cf, chromeName), 
"locale/ja-JP/global/");" in install.js.

locale,install,url,jar:file://H|/mozilla/M18-10-6/bin/chrome/ja-JP.jar!/locale/
ja-JP/global/
(Reporter)

Comment 22

17 years ago
That's exactly the problem this bug is aimed at solving.
(Reporter)

Comment 23

17 years ago
Can't see that I'll get this by the PDT. Guess we'll have to ship a 6.01 upgrade
so l10n can install new locales correctly.
Whiteboard: [rtm need info] → [rtm-]
(Reporter)

Updated

17 years ago
Keywords: nsbeta1
Priority: P3 → P2
Target Milestone: mozilla0.6 → mozilla0.9
(Reporter)

Updated

17 years ago
Whiteboard: [rtm-] → [xpiprd][rtm-]
(Reporter)

Comment 24

17 years ago
Moz 0.8 tasks 
Target Milestone: mozilla0.9 → mozilla0.8

Updated

17 years ago
Blocks: 66909
(Reporter)

Updated

17 years ago
Priority: P2 → P1
(Reporter)

Updated

17 years ago
Target Milestone: mozilla0.8 → mozilla0.9

Updated

17 years ago
Keywords: nsbeta1, rtm → nsbeta1-
Target Milestone: mozilla0.9 → ---
(Reporter)

Comment 25

17 years ago
No, we really do need to do this one because of theme upgrade problems, to make 
sure the user gets back to a safe state. Plussing.
Keywords: nsbeta1- → nsbeta1+
Whiteboard: [xpiprd][rtm-] → [xpiprd]
(Reporter)

Updated

17 years ago
Target Milestone: --- → mozilla0.9

Updated

17 years ago
Blocks: 62177
(Reporter)

Updated

17 years ago
Target Milestone: mozilla0.9 → mozilla0.9.1

Updated

17 years ago
Target Milestone: mozilla0.9.1 → mozilla0.9.3

Updated

17 years ago
Target Milestone: mozilla0.9.3 → mozilla0.9.4
(Reporter)

Updated

17 years ago
Target Milestone: mozilla0.9.4 → mozilla0.9.5

Comment 26

17 years ago
Nominating.
Assignee: dveditz → syd
Status: ASSIGNED → NEW
Keywords: nsbeta1+ → nsbeta1
Target Milestone: mozilla0.9.5 → ---

Updated

16 years ago
Blocks: 104166

Updated

16 years ago
Keywords: nsbeta1
(Reporter)

Comment 27

16 years ago
The raw chrome registry files have recently been collapsed into a single
chrome.rdf file for performance reasons which eliminates the workaround hack
localizers have been employing of overwriting one of the files to select the
default language. The same issues come up for default skins -- this is now
something we can't keep putting off.
Keywords: mozilla0.9.8

Comment 28

16 years ago
Btw. You can still use chrome.rdf to setup default skin / language during installation.
(Reporter)

Comment 29

16 years ago
Overwriting an existing chrome.rdf is evil -- you have no idea what packages,
skins or locales might be registered in there. It's an OK workaround for an
initial fresh installation from scratch -- is my redundancy making the point?
:-) -- but absolutely the wrong thing to do for an XPInstall to be doing.

Comment 30

16 years ago
It's working on fresh install and installed browser. Chrome.rdf is not overwritten when installing packages with chrome.rdf in properly installed browser (XPInstall method).

Updated

16 years ago
Keywords: nsbeta1+
Target Milestone: --- → mozilla0.9.8

Updated

16 years ago
Status: NEW → ASSIGNED
Keywords: nsbeta1
(Reporter)

Comment 31

16 years ago
Taking these two
Assignee: syd → dveditz
Status: ASSIGNED → NEW

Updated

16 years ago
Target Milestone: mozilla0.9.8 → mozilla1.0
(Reporter)

Updated

16 years ago
Status: NEW → ASSIGNED

Updated

16 years ago
Blocks: 116669

Comment 32

16 years ago
nsbeta1- per ADT/XPInstall triage.
Keywords: nsbeta1+ → nsbeta1-, relnote

Comment 33

16 years ago
Please update this bug with an [adt1] - [adt3] impact rating (or take it off the
list if it doesn't even rate adt3.)  Thanks!

Comment 34

16 years ago
Hi, Dan: do you plan to work on this? If not, do you mind if we take it over? thx!
(Reporter)

Comment 35

16 years ago
Feel free, I'd like to review though.

I was imagining a syntax like

  int status selectChrome( type, chromeName [, package] )

Where type is all the values registerChrome() supports except CONTENT (i.e.,
support PROFILE_CHROME and DELAYED_CHROME in addition to SKIN and LOCALE).
chromeName is self-explanatory, and the optional package is to allow authors to
select chrome for only those packages for which the chrome is provided. You
could support a list, or just make people enter multiple lines if you like,
probably a rare use. Not sure it's supportable in installed-chrome.txt
(delayed_chrome style).

Comment 36

16 years ago
Hi, Juraj: Please work with dveditz on this. thx!
Assignee: dveditz → jbetak
Status: ASSIGNED → NEW
accepting
Status: NEW → ASSIGNED

Updated

16 years ago
Keywords: nsbeta1- → nsbeta1+
Priority: P1 → P2
Target Milestone: mozilla1.0 → mozilla1.2alpha
Dan,

just trying to establish what needs to be done. While surveying the source and 
useful APIs I stumbled upon this:

http://lxr.mozilla.org/seamonkey/source/xpinstall/src/nsJSInstall.cpp#1839
http://lxr.mozilla.org/seamonkey/source/rdf/chrome/src/nsChromeRegistry.cpp#1732

It seems like I need to flesh out the InstallSelectChrome function in 
nsJSInstall.cpp. On the chrome backend, I'm tempted to follow what's being done 
for SelectSkin and SelectLocale - namely using SetProvider.

I hope to be able to get this done by Sept. 4 - I'm also helping out Syd and 
Curt on MRE...
Arg, have to continue the "tradition" of pushing this out. Raising priority, I'd
really like to get this done soon.
Keywords: mozilla0.9.8, relnote
Priority: P2 → P1
Target Milestone: mozilla1.2alpha → mozilla1.3alpha

Comment 40

15 years ago
--> tao for reconsideration
Assignee: jbetak → tao
Status: ASSIGNED → NEW
Keywords: nsbeta1+ → nsbeta1
Installer triage team: nsbeta1-
Keywords: nsbeta1 → nsbeta1-

Comment 42

15 years ago
Hi, Bob: please reassign these i18n/l10n/l12y bugs accordingly. thx!
Assignee: tao → bobj
Assignee: bobj → nobody
QA Contact: jimmykenlee → xpi-engine
(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.