GNU bug report logs - #61914
IceCat does not start with en_GB.utf8 locale

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 61914 in the body.
You can then email your comments to 61914 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Timo Wilken <timo.wilken <at> cern.ch>
To: <bug-guix <at> gnu.org>
Subject: IceCat does not start with en_GB.utf8 locale
Date: Thu, 2 Mar 2023 13:33:20 +0100

I cannot start IceCat with a non-C locale. It opens an almost-blank
window, and I cannot open new tabs or navigate to any URL.

If I run `LANG=C icecat', then it works fine.

I use `guix system' and `guix home', and have IceCat installed in my
`guix home' profile.

I have my operating-system configured with the following locales:

(locale "en_GB.utf8")
(locale-definitions
 (list (locale-definition (name "en_GB.utf8") (source "en_GB"))
       (locale-definition (name "en_US.utf8") (source "en_US"))
       (locale-definition (name "fr_FR.utf8") (source "fr_FR"))))

This is the output when running IceCat in my terminal (without
explicitly setting LANG, so that it retains its value of
"en_GB.utf8"):

$ icecat
ATTENTION: default value of option mesa_glthread overridden by environment.
ATTENTION: default value of option mesa_glthread overridden by environment.
ATTENTION: default value of option mesa_glthread overridden by environment.
JavaScript error: chrome://pocket/content/SaveToPocket.jsm, line 130: NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIStringBundle.formatStringFromName]
JavaScript error: chrome://browser/content/tabbrowser.js, line 7004: NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIStringBundle.GetStringFromName]
JavaScript error: chrome://browser/content/tabbrowser-tabs.js, line 64: NS_ERROR_UNEXPECTED: Component returned failure code: 0x8000ffff (NS_ERROR_UNEXPECTED) [nsIStringBundle.GetStringFromName]
JavaScript error: resource:///modules/sessionstore/SessionStore.jsm, line 2458: TypeError: browser is undefined
JavaScript error: resource:///modules/UrlbarInput.jsm, line 2641: NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIStringBundle.GetStringFromName]
JavaScript error: chrome://browser/content/browser.js, line 8052: TypeError: browser is undefined
JavaScript error: resource:///modules/sessionstore/TabStateFlusher.jsm, line 230: TypeError: browser is undefined
Missing chrome or resource URL: resource://gre/modules/UpdateListener.jsm
Missing chrome or resource URL: resource://gre/modules/UpdateListener.sys.mjs
console.error: "Error during quit-application-granted: [Exception... \"File error: Not found\"  nsresult: \"0x80520012 (NS_ERROR_FILE_NOT_FOUND)\"  location: \"JS frame :: resource:///modules/BrowserGlue.jsm :: _onQuitApplicationGranted/tasks< :: line 1996\"  data: no]"
$ guix shell glibc -- locale
LANG=en_GB.utf8
LC_CTYPE="en_GB.utf8"
LC_NUMERIC="en_GB.utf8"
LC_TIME="en_GB.utf8"
LC_COLLATE="en_GB.utf8"
LC_MONETARY="en_GB.utf8"
LC_MESSAGES="en_GB.utf8"
LC_PAPER="en_GB.utf8"
LC_NAME="en_GB.utf8"
LC_ADDRESS="en_GB.utf8"
LC_TELEPHONE="en_GB.utf8"
LC_MEASUREMENT="en_GB.utf8"
LC_IDENTIFICATION="en_GB.utf8"
LC_ALL=
$ guix shell glibc -- locale -a
C
en_GB.utf8
en_US.utf8
fr_FR.utf8
POSIX
$ guix describe
Generation 2	Mar 02 2023 13:25:29	(current)
  [one non-free channel omitted]
  guix a7763e0
    repository URL: https://git.savannah.gnu.org/git/guix.git
    branch: master
    commit: a7763e067d86908210758aab80d33e4f8b815b1c

GUIX_PACKAGE_PATH="/home/twilken/src/guix-decls"
$ ls -l "$(which icecat)"
lrwxrwxrwx 1 root root 84 Jan  1  1970 /home/twilken/.guix-home/profile/bin/icecat -> /gnu/store/bwcrfgfrri9bpglgb5raih167jaxibkv-icecat-102.8.0-guix0-preview1/bin/icecat

Message #8 received at 61914 <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Timo Wilken <timo.wilken <at> cern.ch>
Cc: 61914 <at> debbugs.gnu.org
Subject: Re: bug#61914: IceCat does not start with en_GB.utf8 locale
Date: Thu, 02 Mar 2023 09:54:31 -0500

Hi Timo,

Timo Wilken <timo.wilken <at> cern.ch> writes:

> I cannot start IceCat with a non-C locale. It opens an almost-blank
> window, and I cannot open new tabs or navigate to any URL.

This is very odd, I've never seen that while testing locales stuff with
IceCat.

> If I run `LANG=C icecat', then it works fine.

Could you try running with a fresh profile?  E.g., 'icecat
--ProfileManager', create a new profile, and start it from there?

It should work.  I suspect the problem may be caused by
'intl.locale.requested' being set to something.  It needs to be unset
for the system locale to be honored, so if that's the problem with your
current profile, you could try clearing it by visiting "about:config" in
the URL bar.

-- 
Thanks,
Maxim

Message #13 received at 61914 <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Timo Wilken <timo.wilken <at> cern.ch>
Cc: 61914 <at> debbugs.gnu.org
Subject: Re: bug#61914: IceCat does not start with en_GB.utf8 locale
Date: Thu, 02 Mar 2023 17:02:31 -0500

Hello Timo,

(Please don't forget to keep the bug in CC so that our discussion
remains public so that anyone can jump in to help!)

Timo Wilken <timo.wilken <at> cern.ch> writes:

> Hi Maxim,
>
> Thanks for your reply!
>
> What finally worked for me was the following:
>
> $ sed -i.bak
> 's|/gnu/store/hhfcn8viysyz2qz9rvvqkj91i5nxzd9s|/gnu/store/bwcrfgfrri9bpglgb5raih167jaxibkv|g'
> \
>       ~/.mozilla/icecat/vfc41hol.default/extensions.json \
>       ~/.mozilla/icecat/vfc41hol.default/addonStartup.json.lz4
>
> After running that, IceCat suddenly worked fine.
>
> No directory starting with /gnu/store/hhfcn8viysyz2qz9rvvqkj91i5nxzd9s
> exists on my system.
>
> I guess that means the "guix gc" I did yesterday is to blame!

> There were lots of entries like the following in my extensions.json:
>
> "rootURI":"jar:file:///gnu/store/hhfcn8viysyz2qz9rvvqkj91i5nxzd9s-icecat-102.8.0-guix0-preview1/lib/icecat/browser/extensions/langpack-xh <at> icecat.mozilla.org.xpi!/",
>
> ...and then when guix gc deleted an old IceCat directory, these files
> were gone.

Interesting.  I would have expected that the language packs extensions,
which are shipped with icecat itself (they are in its application global
directory, under for example
/gnu/store/...-icecat-102.8.0-guix0-preview1/lib/icecat/browser/extensions),
would have self-updated when the browser would have changed.

Perhaps it depends on the version string of icecat changing, or their
date stamp, which is purposefully set to 1970 for reproducibility.

Browsing about:config, I see:

--8<---------------cut here---------------start------------->8---
extensions.systemAddon.update.enabled	false
--8<---------------cut here---------------end--------------->8---

I wonder if this could make a different to be set to true instead.  It's
set to false by the makeicecat.sh script we run to transform the Firefox
source into GNU IceCat.  I guess we'll have to look at the source for
more clues as to how language pack updates are handled exactly.

-- 
Thanks,
Maxim

Message #16 received at 61914 <at> debbugs.gnu.org (full text, mbox):

From: Timo Wilken <timo.wilken <at> cern.ch>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: 61914 <at> debbugs.gnu.org
Subject: Re: bug#61914: IceCat does not start with en_GB.utf8 locale
Date: Thu, 2 Mar 2023 17:37:23 +0100

Hi Maxim,

Thanks for your reply!

What finally worked for me was the following:

$ sed -i.bak 's|/gnu/store/hhfcn8viysyz2qz9rvvqkj91i5nxzd9s|/gnu/store/bwcrfgfrri9bpglgb5raih167jaxibkv|g' \
      ~/.mozilla/icecat/vfc41hol.default/extensions.json \
      ~/.mozilla/icecat/vfc41hol.default/addonStartup.json.lz4

After running that, IceCat suddenly worked fine.

No directory starting with /gnu/store/hhfcn8viysyz2qz9rvvqkj91i5nxzd9s
exists on my system.

I guess that means the "guix gc" I did yesterday is to blame!

There were lots of entries like the following in my extensions.json:

"rootURI":"jar:file:///gnu/store/hhfcn8viysyz2qz9rvvqkj91i5nxzd9s-icecat-102.8.0-guix0-preview1/lib/icecat/browser/extensions/langpack-xh <at> icecat.mozilla.org.xpi!/",

...and then when guix gc deleted an old IceCat directory, these files
were gone.

Is there some way of forcing IceCat not to embed the /gnu/store path
in the user's profile at runtime?

On Thu Mar 2, 2023 at 3:54 PM CET, Maxim Cournoyer wrote:
> Could you try running with a fresh profile?  E.g., 'icecat
> --ProfileManager', create a new profile, and start it from there?

This works, as does using icecat --safe-mode (which presumably avoids
loading all extensions and language packs). The new profile has the
right /gnu/store paths embedded in extensions.json (i.e. those
pointing to the "current" IceCat). I suppose this will blow up as well
on the next guix gc...

> It should work.  I suspect the problem may be caused by
> 'intl.locale.requested' being set to something.  It needs to be unset
> for the system locale to be honored, so if that's the problem with your
> current profile, you could try clearing it by visiting "about:config" in
> the URL bar.

This setting was already cleared.

Cheers,
Timo

Message #19 received at 61914 <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Timo Wilken <timo.wilken <at> cern.ch>
Cc: 61914 <at> debbugs.gnu.org
Subject: Re: bug#61914: IceCat does not start with en_GB.utf8 locale
Date: Fri, 03 Mar 2023 10:44:30 -0500

Hi,

Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes:

[...]

> Browsing about:config, I see:
>
> extensions.systemAddon.update.enabled	false
>
> I wonder if this could make a different to be set to true instead.  It's
> set to false by the makeicecat.sh script we run to transform the Firefox
> source into GNU IceCat.  I guess we'll have to look at the source for
> more clues as to how language pack updates are handled exactly.

I have the same problem, where the French language pack I used with a
previous version of IceCat (102.7.0) is not updating to the
system-provided one.  Setting 'extensions.systemAddon.update.enabled' to
'true' does not help.

I've now reported the issue upstream:
https://bugzilla.mozilla.org/show_bug.cgi?id=1820196.

I've also taken a peek at the source, and it seems the update/cache of
language pack modules would be handled in the
toolkit/mozapps/extensions/internal/XPIDatabase.jsm, e.g. in
processFileChanges and updateExistingAddon.  It seems the cache should
be invalidated in our situation, based on the comment and logic:

--8<---------------cut here---------------start------------->8---
  /**
   * Updates the databse metadata for an existing add-on during database
   * reconciliation.
   *
   * @param {AddonInternal} oldAddon
   *        The existing database add-on entry.
   * @param {XPIState} xpiState
   *        The XPIStates entry for this add-on.
   * @param {AddonInternal?} newAddon
   *        The new add-on metadata for the add-on, as loaded from a
   *        staged update in addonStartup.json.
   * @param {boolean} aUpdateCompatibility
   *        true to update add-ons appDisabled property when the application
   *        version has changed
   * @param {boolean} aSchemaChange
   *        The schema has changed and all add-on manifests should be re-read.
   * @returns {AddonInternal?}
   *        The updated AddonInternal object for the add-on, if one
   *        could be created.
   */
  updateExistingAddon(
    oldAddon,
    xpiState,
    newAddon,
    aUpdateCompatibility,
    aSchemaChange
  ) {
    XPIDatabase.recordAddonTelemetry(oldAddon);

    let installLocation = oldAddon.location;

    // Update the add-on's database metadata from on-disk metadata if:
    //
    //  a) The add-on was staged for install in the last session,
    //  b) The add-on has been modified since the last session, or,
    //  c) The app has been updated since the last session, and the
    //     add-on is part of the application bundle (and has therefore
    //     likely been replaced in the update process).
    if (
      newAddon ||
      oldAddon.updateDate != xpiState.mtime ||
      (aUpdateCompatibility && this.isAppBundledLocation(installLocation))
    ) {
      newAddon = this.updateMetadata(
        installLocation,
        oldAddon,
        xpiState,
        newAddon
      );
    } else if (oldAddon.path != xpiState.path) {
      newAddon = this.updatePath(installLocation, oldAddon, xpiState);
    } else if (aUpdateCompatibility || aSchemaChange) {
      newAddon = this.updateCompatibility(
        installLocation,
        oldAddon,
        xpiState,
        aSchemaChange
      );
    } else {
      newAddon = oldAddon;
    }

    if (newAddon) {
      newAddon.rootURI = newAddon.rootURI || xpiState.rootURI;
    }

    return newAddon;
  },
--8<---------------cut here---------------end--------------->8---

To be continued...

-- 
Thanks,
Maxim

Message #22 received at 61914 <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Timo Wilken <timo.wilken <at> cern.ch>
Cc: 61914 <at> debbugs.gnu.org
Subject: Re: bug#61914: IceCat does not start with en_GB.utf8 locale
Date: Mon, 06 Mar 2023 09:48:42 -0500

Hi Timo,

Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes:

> Hi,
>
> Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes:
>
> [...]
>
>> Browsing about:config, I see:
>>
>> extensions.systemAddon.update.enabled	false
>>
>> I wonder if this could make a different to be set to true instead.  It's
>> set to false by the makeicecat.sh script we run to transform the Firefox
>> source into GNU IceCat.  I guess we'll have to look at the source for
>> more clues as to how language pack updates are handled exactly.
>
> I have the same problem, where the French language pack I used with a
> previous version of IceCat (102.7.0) is not updating to the
> system-provided one.  Setting 'extensions.systemAddon.update.enabled' to
> 'true' does not help.
>
> I've now reported the issue upstream:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1820196.

Trying to reproduce the above, I'm not sure if I still can!  One
hypothesis, is that perhaps I had installed the french language pack
(the .xpi file produced by Guix) manually while testing.  I also
remember testing other languages, such as with LC_ALL=es_ES.utf8, and I
don't see the problem where that one "stuck".  It could be because I
hadn't tried with an older version, but not having a clear reproducers
make things muddy.

Could it be that you had previously installed the language packs
manually?

-- 
Thanks,
Maxim

Message #27 received at 61914-done <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Timo Wilken <timo.wilken <at> cern.ch>
Cc: 61914-done <at> debbugs.gnu.org
Subject: Re: bug#61914: IceCat does not start with en_GB.utf8 locale
Date: Mon, 28 Aug 2023 18:45:53 -0400

Hi,

Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes:

> Hi Timo,
>
> Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes:
>
>> Hi,
>>
>> Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes:
>>
>> [...]
>>
>>> Browsing about:config, I see:
>>>
>>> extensions.systemAddon.update.enabled	false
>>>
>>> I wonder if this could make a different to be set to true instead.  It's
>>> set to false by the makeicecat.sh script we run to transform the Firefox
>>> source into GNU IceCat.  I guess we'll have to look at the source for
>>> more clues as to how language pack updates are handled exactly.
>>
>> I have the same problem, where the French language pack I used with a
>> previous version of IceCat (102.7.0) is not updating to the
>> system-provided one.  Setting 'extensions.systemAddon.update.enabled' to
>> 'true' does not help.
>>
>> I've now reported the issue upstream:
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1820196.
>
> Trying to reproduce the above, I'm not sure if I still can!  One
> hypothesis, is that perhaps I had installed the french language pack
> (the .xpi file produced by Guix) manually while testing.  I also
> remember testing other languages, such as with LC_ALL=es_ES.utf8, and I
> don't see the problem where that one "stuck".  It could be because I
> hadn't tried with an older version, but not having a clear reproducers
> make things muddy.
>
> Could it be that you had previously installed the language packs
> manually?

I haven't heard back from you, and I wasn't able to reproduce the
problem, so I'm tentatively closing this.  Please do reopen if you still
encounter the problem (and ideally, can narrow down a reproducer).

-- 
Thanks,
Maxim

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.