46491 - string bundles should not depend on chrome

Status: VERIFIED FIXED

(Core :: Internationalization, defect, P3)

Description

[Warren Harris]

Right now, if you need a string bundle you have to specify the bundle with a 
chrome: url. This loads up the chrome registry which is extremely heavyweight. 
It loads rdf, layout, http, script security manager, and a bunch of other stuff. 
Moreover, chrome and rdf aren't thread-safe (bug 44808), so neither are string 
bundles.

Why do we need to use chrome urls for string bundles? All the user really wants 
it to load global/locale/wizardManager.properties (for instance) according to 
the current localization. This can easily be done with a resource URL by 
defining a "Locale" resource root. Then when changing locales, it can reset this 
root, and flush the string bundle cache.

What do you guys think? I know that chrome deals with locales now, but for 
string bundles, its overkill. Perhaps the chrome registry can use the same 
Locale root when it does its resolution.

Comment 1

[David Hyatt]

Only the chrome registry knows the user's chosen locale, and that dictates which 
string bundles are going to be used.  You have to suck in RDF to know what 
string bundle to use (i.e., which JAR to look in).

Maybe your objection is that RDF is being used at all to save chrome 
information, but since it is, that's where you've got to go to get it.
 

Comment 2

[David Hyatt]

Also, there's no such thing as a single current locale.  Different chrome 
packages can have different locales, e.g., you could have a German navigator and 
a Spanish Neoplanet.

IMO this bug is invalid.

Comment 3

[David Hyatt]

A better bug if this is a concern would be that the chrome registry should be 
rewritten not to use RDF, and if you file it, I'll keep it around, but I won't 
have time to do that before we ship.

Comment 4

[David Hyatt]

One final note.  waterson has a patch that will keep RDF from loading layout.  
That should help things substantially.

Comment 5

[Warren Harris]

I still think chrome is way to heavyweight for this. All the user wants is 
the string bundle for foo.properties in the current locale! The fact that only 
the chrome registry currently knows the current locale is incidental. That could 
be stored anywhere, and the chrome registry could access it from there.

Comment 6

[Warren Harris]

If you think the chrome registry shouldn't use rdf long-term, then we should 
definitely fix that for beta3. We're telling developers that rdf is the one true 
way to write chrome manifests.

Comment 7

[David Hyatt]

I'm pretty agnostic about the underlying storage mechanism.  I used RDF because 
it was there and implemented.  

Even using RDF, I think that right now we're loading way too much when we bring 
in the chrome registry, and it would be more practical to tackle that than to 
rewrite the registry.

For example, we were loading layout.  waterson fixed that.  Also, we're loading 
RDF, but RDF is only heavyweight because it includes all of the XUL content 
model.  waterson is going to be breaking that out into its own DLL, and once he 
does that, RDF will be pretty small.

You mention http.  How is that getting sucked in?  The chrome registry maps to 
resource URLS, which in turn map to file URLs.  That sounds like a bug.

Script security manager doesn't need to load.  That's probably some problem in 
the XML content sink.  Since we don't really build a DOM document out of the 
data, we don't need to check any kind of script security.

I think there's a lot of good work we could do to break some dependencies 
between modules here.

Comment 8

[Chris Waterson]

Just checked in fix for 46013, which was essentially "rdf loads layout when 
reading RDF/XML". see also bug 43121, pull XUL content model out of RDF DLL. I 
tend to agree with hyatt: properly factoring code could go a long way here.

Comment 9

[Mitchell Stoltz (not reading bugmail)]

Hyatt,
  Script security manager is called in by nsChromeProtocolHandler to assign the 
system principal to chrome. You're right that when the chrome we're loading isn't 
xul content or whatever which might contain script (just a localized string in 
this case), we don't need to invoke security manager. The trick will be 
distinguishing those situations.

Comment 10

[tao]

Other than the caching mechanism of property files, Stringbundle does not 
have direct dependency on chrome. Reassign to Alecf who is moving the caching
to necko.

Please bounce back if you see otherwise.

Comment 11

[Alec Flett]

Heh, I thought this was already assigned to me.
In any case, yep I'm already working on this... I have a plan of attack, I just
need to implement it.

Comment 12

[Alec Flett]

Fixed. string bundles are now blindly cached by URI, but flushed by chrome when 
the locale changes.

Comment 13

[Teruko Kobayashi]

Verified.