Since the embed.jar files are composed of messaging specifically tailored for the Mozilla client an override mechanism is needed. "Custom.jar" would contain a subset of the embed.jar messages that would allow customization or partial elimination of the standard messaging provided by embed.jar. This will allow the development community the ability to easily customize the internal browser messaging without having to create a special build or maintain special versions of embed.jar.

ooh, I got bug 160000! Anyhow. Rick, chak and I discussed this for a bit and decided there were two basic ways of fixing this: 1) specifically looking for a custom.jar and then hijacking the chrome registry to resolve certain filenames there first, before checking the jar were the file is expected. 2) changing the way the chrome registry works such that we can have jar paths much like CLASSPATH in java. 2) is a beast, but is really where we want to go ultimately. I think for our first pass at this, we'll do 1) and I'll do my best to leave openings in the chrome registry for 2). how this fits in with bug 119923, I'm not sure.

I argued elsewhere that we should allow embedders to provide all of their own strings. Should that be addressed here too?

perhaps - did you mean something beyond overriding a specific .properties file?

I meant doing away with Gecko .properties files altogether. An embedder might want to do all their localization in platform-specific resoures, and not deal with Gecko-style localization at all, and they might want to customize the UI strings for their product. If we were to do this, we'd have to feed the embedder with string keys that they'd use to look up localized strings in their own resources.

ah! ok That would be an entirely different bug... I think we really need to extend the string bundle library in order to get that functionality. It sounds very useful though. Do you mind filing a bug against me on that?

I agree with Simon that embeddors/localization teams are more familiar with platform specific resources and may not want to deal with .properties files. Alec : Is that not a lot more work(not only on coding but the impact on our current localization). If we want to go that route, we should file another bug and handle it separately. The current custom.jar proposal which Alec's been investigating is needed by a certain major embedding customer asap and has a very high priority.

I filed bug 160165 on allowing embedders to provide their own UI strings.

Just a quick comment on the proposed "custom.jar". I would prefer the override file to be a flat text file. That would make source management much easier than if the file is a jar/zip binary format.

um, version control should control the original (optionally flat) file. i'm sure the major vendor doesn't want someone coming over to a computer and randomly twiddling or entirely destroying this file. The consequences could be disastrous. (In fact, I'd suggest that we support and even require signed jars for core files, but ...)

The original file could be a flat file(for version control purposes) which gets turned into a JAR file during build time. When we have easy to use signing tools (which actually work) then we can start thinking about using singed JARs. For now, let's keep it simple.

ok, I think I've figured out a reasonable plan for this. here's how this will work: the chrome registry will act as a pre-resolver for the jar protocol (I didn't want to burden the jar protocol with this functionality) basically when a chrome file is requested, the chrome registry will first convert the url to a form like jar:resource:/res/custom.jar!/<packagename>/<packagetype>/<key>/<path> so that chrome://navigator/locale/navigator.properties would first get resolved to jar:resource:/res/custom.jar!/navigator/locale/en-US/navigator.properties the "key" would correspond to the current setting for the packagetype - for instance "locale" would have the key "en-US" and "skin" would have the key "modern" - I don't think "content" has a key, so I could leave it out for content. the tricky part is going to be checking if the file exists before passing it back to consumers

oh, one other thing - the chrome registry will cache the custom.jar file (as an nsIJAR I think) so that it can do quick lookups to determine if each requested file is actually in custom.jar.. the trick will be somehow sharing this with the jar protocol and avoid having the file open twice by two seperate modules - hopefully libjar will do this for me? need to look into that.

good news, I have a working cut of this.. I haven't tested it thoroughly but I'm pretty confident what I have will work fine. I'll post the patch in a few hours, after I finish testing... the patch is big because I had to whack the heck out of the chrome registry interface, because it was doing some nasty things with strings in a few of the functions I needed to touch..and the rippling effect affected most of the methods in nsIXULChromeRegistry...

Here's a patch which includes the fixes for bug 162741.. I'm still waiting for reviews in that bug, then I will be able to generate a smaller patch for this bug.

ok, bug 162741 has been fixed, so this is the final patch. Basically this allows the file to be overridden in a custom.jar file which should be installed in your chrome directory.

Comment on attachment 96065 [details] [diff] [review] use custom.jar if it exists sr=hyatt

Comment on attachment 96065 [details] [diff] [review] use custom.jar if it exists r=chak

alright! fix is in. thanks everyone.

batch: adding topembed per Gecko2 document http://rocknroll.mcom.com/users/marek/publish/Gecko/Gecko2Tasks.html

To Dharma for verification