[Bug 677815]

[Dtownsend]

(In reply to David McNamara [:mackers] from comment #3)
> r94029 has a potential fix for this.
> 
> When ACR detects that a major application upgrade has occurred, it will
> *uninstall* all locales, and then restart the browser. This will mean that
> Firefox can at least start with a working UI.
> 
> For some reason, merely disabling the locales does not have any effect. I
> suspect this is because the addon manager is not yet watching for addon
> disables when we need to disable it (when the broken UI comes up), but
> uninstalling the addon will trigger the uninstall immediately.

This is a little surprising, not sure why that'd be the case.

> I'm not sure it is desireable that we uninstall all locales in this
> instance, but this behaviour must be better than seeing a broken UI.

As I understand things the UI by default uses the system locale and
attempts to find chrome packages registered for that, however my
understanding is that there are prefs you can set to override this and
use a specific locale. Perhaps you can just set these prefs on startup
to force it to use the app-shipped locale for that startup while you
handle disabling the other locale packs.

> I am also looking for some clarification on locale vs langpack in this
> regard, as the AddonManager returns "locale" as the addon type, regardless.

As far as the add-on manager is concerned we have an extension type
"locale" which ships localized strings. Langpacks are all of this type.
Technically it is possible to ship localizations for only a part of the
UI in a "locale" xpi, but I don't think this ever happens in a reality
so there is basically a 1:1 mapping here.

-- 
You received this bug notification because you are a member of Mozilla
Bugs, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/677815

Title:
  Firefox crashes with XML Parsing Error

To manage notifications about this bug go to:
https://bugs.launchpad.net/firefox/+bug/677815/+subscriptions