216489 - registerChrome() doesn't set |selectedSkin| and |selectedLocale|

Status: RESOLVED INCOMPLETE

(Core :: XUL, defect)

Description

[HJ]

Steps to reproduce:
1) vanilla installation of mozilla (doesn;t for with FB)
1) use a new profile 
2) select the modern theme (restart when needed)
3) download/install from http://multizilla.mozdev.org/installation.html
4) restart mozilla

Current result : classic skin selected for tabs and buttons
Expected result: modern skin selected for tabs and buttons

This is what we use in install.js

registerChrome(PACKAGE | G_CHROME_TYPE, getFolder(G_CHROME_LOC, G_JAR_FILE),
G_CONTENT);
registerChrome(SKIN    | G_CHROME_TYPE, getFolder(G_CHROME_LOC, G_JAR_FILE),
G_MODERN_SKIN);
registerChrome(SKIN    | G_CHROME_TYPE, getFolder(G_CHROME_LOC, G_JAR_FILE),
G_CLASSIC_SKIN);
registerChrome(LOCALE  | G_CHROME_TYPE, getFolder(G_CHROME_LOC, G_JAR_FILE),
G_LOCALE);

So there are to registerChrome()'s in install.js 
And this is the result: 

chrome.rdf (before the MultiZilla installation):
  <RDF:Description about="urn:mozilla:package:multiviews">
    <c:selectedLocale resource="urn:mozilla:locale:en-US:multiviews"/>
    <c:selectedSkin resource="urn:mozilla:skin:modern/1.0:multiviews"/>
  </RDF:Description>

chrome.rdf (after the MultiZilla installation):installation:
  <RDF:Description about="urn:mozilla:package:multiviews">
    <c:selectedLocale resource="urn:mozilla:locale:en-US:multiviews"/>
    <c:selectedSkin resource="urn:mozilla:skin:classic/1.0:multiviews"/>
   </RDF:Description>

registerChrome() should somehow check for the currently selected skin, in case
it locates more than one...

Comment 1

[HJ]

Darn: s/(doesn;t for with FB)/(doesn't work with mozillaFirebird)

Comment 2

[Maxx]

I found this strange that it could be a bug in Mozilla extension installer,
because using the other good tab extension for mozilla doesn't have this skin bug.

(The other tab extension is Tabbrowser Extensions :
http://extensionroom.mozdev.org/#tbe and this extension seems to be the same
kind of replacement of the tab toolbar of mozilla. so...)

Comment 3

[Karsten Düsterloh]

I believe this to be the problem:
When installing an addon, the selectedLocale and selectedSkin attributes in the
profile chrome are *not* set. When the addon is first used, Mozilla selects the
first locale or skin it finds if that has data for this addon, eg:

  <RDF:Seq about="urn:mozilla:locale:root">
    <RDF:li resource="urn:mozilla:locale:it-IT"/>
    <RDF:li resource="urn:mozilla:locale:fr-FR"/>
    <RDF:li resource="urn:mozilla:locale:en-US"/>
  </RDF:Seq>

If it-IT has locale data for the addon, selectedLocale is set accordingly.
If it-IT has *no* locale data for the addon, we get the infamous red XUL error
area...

Comment 4

[Benjamin Smedberg]

I just attached a patch to bug 246014 that will take care of this for
new-toolkit apps. It might be possible to backport that approach to seamonkey,
though it doesn't look easy, because you'd have to hack a lot of stuff in
pref-themes.js and locale-selection and profile code.

Comment 5

[HJ]

(In reply to comment #4)
> I just attached a patch to bug 246014 that will take care of this for
> new-toolkit apps. It might be possible to backport that approach to seamonkey,
> though it doesn't look easy, because you'd have to hack a lot of stuff in
> pref-themes.js and locale-selection and profile code.

I sure hope you can find some time to fix this. This will most certainly help me
and all other Mozilla users...

Comment 6

[Benjamin Smedberg]

I will not be working on this for seamonkey, though I will help interested
volunteers. Porting seamonkey to the new toolkit would IMO be a better long-term
plan.

Comment 7

[Karsten Düsterloh]

JFTR: The solution of bug 265760 (adding chrome:name) seems to work around the
locale side of this bug as described in comment #3 (at least wrt to the Red XUL
Errors)...

Comment 8

[HJ]

(In reply to comment #6)
> I will not be working on this for seamonkey, though I will help interested
> volunteers. 

We really needs this fixes, so guess I will have to be that volunteer one day,
but I cannot compile Mozilla (I can compile but have regal restrictions at work
and I won't be home for another 5 months or so). So, are you willing to do that,
after I finished the patch?

>Porting seamonkey to the new toolkit would IMO be a better long-term plan.

Are you talking about the BE, FE or both?

Comment 9

[Manuel Reimer]

(In reply to comment #7)
> JFTR: The solution of bug 265760 (adding chrome:name) seems to work around the
> locale side of this bug as described in comment #3 (at least wrt to the Red XUL
> Errors)...

Here the source of the file mentioned in bug 265760:
http://lxr.mozilla.org/aviarybranch/source/extensions/inspector/resources/locale/en-US/contents.rdf#12

How good does this fix work? So far I use an really bad workaround in the
PrefBar installer. If this "fix" really works I could simplify my installer very
much!

Comment 10

[Jakub Narebski]

Mozilla/5.0 (Windows; U; Win98; pl-PL; rv:1.7.5) Gecko/20041217 MultiZilla/1.7.0.2d

WORKSFORME. Probably was FIXED either in Mozilla code, or in Multizilla code.

See also: http://www.mozdev.org/bugs/show_bug.cgi?id=3433 (Multizilla bug report)

Comment 11

[Michael]

(RE: comment #6)
From:
http://wiki.mozilla.org/SeaMonkey:Project_Goals#Future_Releases

I take it this means that development of Mozilla will continue but not by the
Mozilla Foundation. And that the plan is to backport the New Toolkit from
Firefox as per your suggestion.

Comment 12

[Benjamin Smedberg]

the old chrome registry/xpinstall code is completely dead