Firefox crashes with XML Parsing Error

[David Stansby]

Binary package hint: firefox

The newest version of Firefox installed from the Natty repositories crashes on startup with the following message:

XML Parsing Error: undefined entity
Location: chrome://browser/content/browser.xul
Line Number 232, Column 5: <key id="key_openAddons" key="&addons.commandkey;" command="Tools:Addons" modifiers="accel,shift"/>
----^

Firefox 4b7 downloaded straight from Mozilla is running fine.

ProblemType: Bug
DistroRelease: Ubuntu 11.04
Package: firefox 4.0~b7+nobinonly-0ubuntu2
ProcVersionSignature: Ubuntu 2.6.37-2.10-generic 2.6.37-rc1
Uname: Linux 2.6.37-2-generic i686
NonfreeKernelModules: wl
Architecture: i386
Date: Sat Nov 20 12:30:08 2010
InstallationMedia: Ubuntu 10.04 LTS "Lucid Lynx" - Release i386 (20100429)
ProcEnviron:
 PATH=(custom, user)
 LANG=en_GB.utf8
 SHELL=/bin/bash
SourcePackage: firefox

[Chris Coulson (chrisccoulson)]

Hmmm, works ok here. This happens after you restarted? Are you running the abrowser-branding package or firefox--branding? Does this happen if you start with -safe-mode?

[David Stansby (dstansby-deactivatedaccount)]

- Still happens after restart
- Doesn't happen if I run firefox -safe-mode
- I don't have abrowser-branding installed
- I do have firefox-branding installed

[Chris Coulson (chrisccoulson)]

The type of error you see and the fact that -safe-mode works suggests that it's either an extension which is breaking it, or something else is wrong with your profile, and so far, you seem to be the only person with this problem.

Please report firefox bugs with ubuntu-bug, as the apport hook attaches interesting information about your profile, which saves us a bunch of time asking questions. Please run apport-collect 677815 to attach this information.

Could you also try with a fresh profile.

Thanks

[Chris Coulson (chrisccoulson)]

Have you disabled the addon compatibility check btw? (extensions.checkCompatibility)

[David Stansby (dstansby-deactivatedaccount)]

Now working fine.

[Marcio Merlone (mmerlone)]

This is also happening with my brand new FF 4.0 on Ubuntu 10.10. Just installed a couple of extensions and now it crashes.

[MilchFlasche (robertus0617)]

Hmmm, also occuring with my Firefox 4.0 Gold just installed with mozilla-stable PPA. I'm on Kubuntu 10.04. I'm using a profile copied from Minefield 4.0b13pre (which is working well side-by-side with mainstream Firefox) containing many add-ons.

[Chris Coulson (chrisccoulson)]

Try disabling addons. This isn't a firefox bug, but it's either:

- A bug with one of your addons which claims to support 4.0 (even though it doesn't)
- You've disabled the addon compatibility checker, which is designed to protect you against this exact problem.

[MilchFlasche (robertus0617)]

I have disabled all my add-ons through the safe mode, however Firefox 4 still stucks with the Add-on Manager, which does not load at all, preventing switching to other tabs. Screenshot attached.

[MilchFlasche (robertus0617)]

I have just close the window completely (which was restarted from Safe Mode) and re-launched Fx. Now the tabs and Add-on Manager is loading fine. So I should take back #10. I'll test with my add-ons one by one to see which is causing the problem. Thanks for your suggestion.

[MilchFlasche (robertus0617)]

I feel that maybe it's the incompatible language pack (which lags behind Fx release) which is causing the problem again, recalling previous upgrading experiences.

[Gabriel de Perthuis (g2p)]

User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:2.0) Gecko/20100101 Firefox/4.0
Build Identifier: Mozilla/5.0 (X11; Linux x86_64; rv:2.0) Gecko/20100101 Firefox/4.0

Language packs for different firefox versions are never compatible, and they tend to prevent firefox from starting with XUL XML parser errors. The addon compatibility reporter shouldn't override compatibility for these, or if it does, it should disable them first.

Reproducible: Always

Steps to Reproduce:
Steps (these are the upgrade steps I followed; it can probably be done with vanilla firefox tarballs as well): Install the addon compatibility reporter. Install language-pack-en-base and enable the language pack. Install firefox from ppa:mozillateam/firefox-stable .
Actual Results:
On start up, Firefox displays a red xml parser error instead of the UI.

Expected Results:
Firefox starts normally.

Launching `firefox -uilocale en`, and disabling the language pack from the addon manager's language pane, allows firefox to start again.

[Gabriel de Perthuis (g2p)]

It was working when running firefox-4.0 from ubuntu-mozilla-daily/ppa which has the betas and nightlies, and quit working with mozillateam/firefox-stable which has the final firefox 4. This is because the language packs are in /usr/lib/firefox-addons/extensions/ and not /usr/lib/firefox-4.0-addons/extensions/ .

Here is a workaround: `firefox -uilocale en`, go to the addons manager, open the language pack pane, disable language packs.

I filed a bug over there: https://bugzilla.mozilla.org/show_bug.cgi?id=644933

[Briks-si (briks-si)]

Can't turn compat prefs on/off for any particular type. This one could be tricky.

Blair / Dave, any ideas?

[Chris Coulson (chrisccoulson)]

Gabriel - the language packs define compatibility requirements already, and the ones in /usr/lib/firefox-addons/extensions already define maxVersion=3.6.* if you are on a release older than 11.04, which means that they are *not* loaded by Firefox 4. The only reason they would be loaded is if you have disabled the addon compatibility check, which is not a bug in that case.

[Dtownsend (dtownsend)]

Yeah, disabling the locale packs is the only thing I can think of, maybe if you do that early enough in startup it'll work, not sure though.

[Dave-j0p9 (dave-j0p9)]

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.

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.

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

[Briks-si (briks-si)]

cc'ing l10n FYI.

Marking as fixed as we have a solution. If anyone is not happy with it, please reopen.

[Hskupin (hskupin)]

This is a kinda rough method to get rid of the problem. Especially for users who switch between different versions of Firefox, i.e testing purposes. Those would always have to install the language pack again and again when using the same profile.

DaveT, do you have some ideas re comment 3?

[L10n-mozilla (l10n-mozilla)]

The mobile folks work on infrastructure to keep language packs compatible on nightlies. Mark, my bug foo is weak today, which is the best bug to point to right now?

[Dave-j0p9 (dave-j0p9)]

For a definition of what ACR currently defines 'application upgrade', see bug 527249.

[Dtownsend (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.

[Dave-j0p9 (dave-j0p9)]

This feature has been disabled for ACR 0.9.

Re-opening to readdress another day.

[Mark-finkle (mark-finkle)]

(In reply to Axel Hecht [:Pike] from comment #6)
> The mobile folks work on infrastructure to keep language packs compatible on
> nightlies. Mark, my bug foo is weak today, which is the best bug to point to
> right now?

We have a few bugs for Fennec. The original bug was bug 63467, which basicially states the problem - using langpacks XPIs for nightlies means the ngihtly could be busted (yellow screen of death) if a langpack is not up to date.

Bug 678111 outlines some work RelEng is doing to keep langpacks separated by buildid.Fennec will check for langpacks compatible with the new app buildid. If it finds some, they are downloaded with the app update. If we don't find any, we uninstall those langpacks.

[Briks-si (briks-si)]

(In reply to Dave Townsend (:Mossop) from comment #8)
> > 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.

David, could you post the code you tried. Maybe there is a minor error or oversight.

[Briks-si (briks-si)]

(In reply to Mark Finkle (:mfinkle) from comment #10)
> If it finds some, they are downloaded with the app update. If we don't find
> any, we uninstall those langpacks.

The update check and download is probably something we could do as well, but there is still that uninstall part that noone seems to like. I like Mossop's idea of reverting to the app-shipped locale. The pref is general.useragent.locale

[L10n-mozilla (l10n-mozilla)]

You want to set general.useragent.locale to default, and, if it exists, intl.locale.matchOS, too. The latter exists today, but there are plans to phase that out, so you want to be prepared for that just not being there.

[Dave-j0p9 (dave-j0p9)]

(In reply to Brian King (Briks) [:kinger] from comment #11)
> David, could you post the code you tried. Maybe there is a minor error or
> oversight.

In essence the code is the following:

ACR.Util.getInstalledExtensions(function(installedExtensions) {
    for (var i=0; i<installedExtensions.length; i++) {
        if (installedExtensions[i].type == "locale") {
            //installedExtensions[i].userDisabled = true;
            installedExtensions[i].uninstall();
        }
    }
});

In the above, 'uninstall()' works as expected while 'userDisabled = true' has no effect.

Note, ACR restarts the application as soon as it finishes uninstalling/disabling extensions. This may be why the disable does not complete.

A possible solution is to set up extension disable listeners and only to restart the app once all those listeners have been notified.

[Dtownsend (dtownsend)]

(In reply to David McNamara [:mackers] from comment #14)
> (In reply to Brian King (Briks) [:kinger] from comment #11)
> > David, could you post the code you tried. Maybe there is a minor error or
> > oversight.
>
> In essence the code is the following:
>
> ACR.Util.getInstalledExtensions(function(installedExtensions) {
> for (var i=0; i<installedExtensions.length; i++) {
> if (installedExtensions[i].type == "locale") {
> //installedExtensions[i].userDisabled = true;
> installedExtensions[i].uninstall();
> }
> }
> });
>
> In the above, 'uninstall()' works as expected while 'userDisabled = true'
> has no effect.
>
> Note, ACR restarts the application as soon as it finishes
> uninstalling/disabling extensions. This may be why the disable does not
> complete.

When you say that, what do you mean? The code above doesn't show the restart call inside the anonymous function which it is where I would expect it to have to be in order to only happen after the async add-on retrieval has completed.

> A possible solution is to set up extension disable listeners and only to
> restart the app once all those listeners have been notified.

Setting userDisabled should (currently) behave synchronously, so the disable events should be sent before that line even completes.

[Dave-j0p9 (dave-j0p9)]

(In reply to Dave Townsend (:Mossop) from comment #15)
> Setting userDisabled should (currently) behave synchronously, so the disable
> events should be sent before that line even completes.

I'm seeing the correct behaviour now and I can't reproduce the previous erroneous behaviour.

r96097 of ACR has this feature enabled. Any major application upgrade will cause the ACR to:

1. Disable all locales.
2. Reset the 'general.useragent.locale' and 'intl.locale.matchOS' prefs
3. Restart the application.

Tested with Breton langpack on a Firefox 3.6 -> 7.0 upgrade.

[Reşat SABIQ (sabiq)]

I ran into a related issue and logged bug 701631.

I'd appreciate your feedback on the following:
i. Has the fix from comment 16 been included in Firefox 8?
ii. Is the following statement correct based on fix referred to in comment 16?
Even if there's a remote version of the lang pack that is compatible with the upgraded app (say 7.0 upgraded to 8.0), then it will NOT be downloaded, and steps 1., 2., 3. from comment 16 will still be performed.
iii. (In reply to Mark Finkle (:mfinkle) from comment #10)
> Bug 678111 outlines some work RelEng is doing to keep langpacks separated by
> buildid.Fennec will check for langpacks compatible with the new app buildid.
> If it finds some, they are downloaded with the app update. If we don't find
> any, we uninstall those langpacks.
Is buildid idea something that's happening or not? From the install.rdf viewpoint i'm only aware of minVersion and maxVersion. Will they be sufficient in the foreseeable future? Just curious how this buildid idea could affect a lang pack like the following, for instance:
https://addons.mozilla.org/en-US/firefox/addon/QIRIMTATARCA-til-destesi/

P.S. If the answer to question ii. above is yes, i think it's really not user-friendly. In the best case scenario, the user'd have to get another addon update prompt some time later and re-start. I hope the answer is no, cause non-lang-pack addons are updated during an app upgrade, and it should work the same for langpacks IMHO.

[Briks-si (briks-si)]

(In reply to Reşat SABIQ (Reshat) from comment #17)
> i. Has the fix from comment 16 been included in Firefox 8?

That fix is in the ACR extension, not Firefox. ACR 1.0 with the fix will be released very soon.