TB 76 beta 3, first start on a fresh profile:

[Exception... "Component returned failure code: 0x80520001 (NS_ERROR_FILE_UNRECOGNIZED_PATH) [nsIXPCComponents_Utils.readUTF8URI]" nsresult: "0x80520001 (NS_ERROR_FILE_UNRECOGNIZED_PATH)" location: "JS frame :: resource://gre/modules/L10nRegistry.jsm :: L10nRegistry.loadSync :: line 658" data: no]

I see this frequently as well on profiles which have already been in use.

TB 78 beta, first start, Profile working on TB 68, debian-Server, postfix Mail

[Exception... "Component returned failure code: 0x80520001
(NS_ERROR_FILE_UNRECOGNIZED_PATH) [nsIXPCComponents_Utils.readUTF8URI]"
nsresult: "0x80520001 (NS_ERROR_FILE_UNRECOGNIZED_PATH)" location: "JS
frame :: resource://gre/modules/L10nRegistry.jsm ::
L10nRegistry.loadSync :: line 658" data: no] L10nRegistry.jsm:658:19
loadSync resource://gre/modules/L10nRegistry.jsm:658
fetchFile resource://gre/modules/L10nRegistry.jsm:573
generateResourceSetSync resource://gre/modules/L10nRegistry.jsm:478
map self-hosted:240
generateResourceSetSync resource://gre/modules/L10nRegistry.jsm:473
generateResourceSetsForLocaleSync
resource://gre/modules/L10nRegistry.jsm:415
next self-hosted:1099
generateBundlesSync resource://gre/modules/L10nRegistry.jsm:177
next self-hosted:1099
touchNext resource://gre/modules/Localization.jsm:167
regenerateBundles resource://gre/modules/Localization.jsm:552
activate resource://gre/modules/Localization.jsm:243
getRegionDisplayNames resource://gre/modules/mozIntl.jsm:837
getLocaleDisplayNames resource://gre/modules/mozIntl.jsm:897
map self-hosted:240
getLocaleDisplayNames resource://gre/modules/mozIntl.jsm:867
formatLocaleSetLabels
chrome://messenger/content/preferences/general.js:937
init chrome://messenger/content/preferences/general.js:238
init chrome://messenger/content/preferences/preferences.js:42

Still the same with 79.01b

I see these errors in TB 78.0 release version (Japanese locale, 32-bit) immediately after the startup (even in safe mode) under windows 10 pro (64-bit) as well.
See Bug 1653789, TB 78.0: Errors in error console immediately after startup of TB under Windows 10.

There are a few variant of the stack trace.: I am attaching the copy of the five traces.
I think the common factor is "self-hosted".

1. Coming from mailglue?
2. Coming from openpgp?
3. Coming from calendar?
4. Coming from chat / OTR?
5. Coming from chat?

I think "<匿名>" will be probably shown as "<anonymous>" in English locale.

TIA

In the new Version, there is an error message:
Server not found

self-hosted could not be found. Please check the name and try again.

Check the address for typing errors such as ww.example.com instead of www.example.com
If you are unable to load any pages, check your computer's network connection.
If your computer or network is protected by a firewall or proxy, make sure that Thunderbird is permitted to access the Web.

And in error-console:

1596604220924 Telemetry::CoveragePing ERROR no endpoint base set Log.jsm:723
append resource://gre/modules/Log.jsm:723
log resource://gre/modules/Log.jsm:379
error resource://gre/modules/Log.jsm:387
startup resource://gre/modules/CoveragePing.jsm:51
_delayedInitTask resource://gre/modules/TelemetryControllerParent.jsm:826
InterpretGeneratorResume self-hosted:1478
AsyncFunctionNext self-hosted:684
Uncaught ReferenceError: XPCOMUtils is not defined
<anonymous> chrome://global/content/printUtils.js:61

https://support.mozilla.org/en-US/questions/1306053 is about adobe fonts and lists the same L10nRegistry error

I'm not actively on Windows, and I don't use Adobe fonts.
I'll try this later on my wife's MacBook, where she uses some Adobe fonts.

I do not know why, but it works ...

WFM per comment 8

I hate to reopen this, but I am still seeing this with 78.4.2 thunderbird (32bit) under Windows10.
The Windows10 itself is 64-bit.

There are 7 such errors in the console.

Now, however, I get a somewhat different stacktrace from the attachment I posted, but basically
all exceptions are thrown from L10nRegsitry.jsm:658:19

/**
 * This is a synchronous version of the `load`
 * function and should stay completely in sync with it at all
 * times except of the async/await changes.
 *
 * Notice: Any changes to this method should be copied
 * to the `generateResourceSetSync` equivalent below.
 *
 * @param {string} url
 *
 * @returns {string}
 */
L10nRegistry.loadSync = function(uri) {
  try {
    let url = Services.io.newURI(uri);
    let data = Cu.readUTF8URI(url);  <=== This is where the exception is thrown.
    return data;
  } catch (e) {
    if (
      e.result == Cr.NS_ERROR_INVALID_ARG ||
      e.result == Cr.NS_ERROR_NOT_INITIALIZED
    ) {
      try {
        // The preloader doesn't support this url or isn't initialized
        // (xpcshell test). Try a synchronous channel load.
        let stream = NetUtil.newChannel({
          uri,
          loadUsingSystemPrincipal: true,
        }).open();

        return NetUtil.readInputStreamToString(stream, stream.available(), {
          charset: "UTF-8",
        });
      } catch (e) {
        if (e.result != Cr.NS_ERROR_FILE_NOT_FOUND) {
          Cu.reportError(e);   <=== may be a good idea to print URL HERE
        }
      }
    } else if (e.result != Cr.NS_ERROR_FILE_NOT_FOUND) {
      Cu.reportError(e); <=== maybe a good idea to print URL HERE
    }
  }

  return false;
};

I think it is a good idea to print URL to see what is going on. Maybe some non-Windows-compatible path name is passed down the stack?
Or L10nRegistry.jsm does not properly generate the final pathname that is acceptable on host OS?

So I want to change L10nRegistery.jsm to print |url| when the error occurs..
But it is in omni.ja archive.

I have a few questions:
Q1 - what would be the good function to print the URL which would be shown in the error console.
Cc.dump('error URL:' + url) would be just fine?
Q2 - what is the proper way to edit omni.ja arcihve that is bundled with the official distribution of TB.
I can edit .zip archive in the following manner.

• save omni.ja : copy omni.ja -> omini.ja.saved-copy
• rename omni.ja to omni.zip so that I can unzip and edit the L10nRegistery.jsm inside and zip the files again.
  (Actually, I can do the above step automagically by using GNU Emacs. It groks .zip archive and allows me to edit the file inside and write it back to produce the edited zip archive automatially.)
• copy back the edited omni.zip to omni.ja

All is set, well ALMOST.
Now I think there are a few steps to invalidate the JSM cache after I change L10nRegistry.jsm if I recall correctly.

Can anyone shed light on Q1 and Q2 above?
I can tinker with Q1, but I am a bit hazy about Q2.

TIA

The following page states a few tricks
to invaidate JS cache. But the command line option part is not convincing. (It "claims" invalidation to happen.)
https://developer.thunderbird.net/add-ons/tips-and-tricks

The following page suggests use of console.log().

https://developer.mozilla.org/en-US/docs/Web/API/Console/log
Don't use console.log(obj), use console.log(JSON.parse(JSON.stringify(obj))).

If there are pitfalls of using the above function and the approaches to invalidate cache please let me know.

TIA

I changed the code of LN10nRegister.jsm thusly and obtained the attached dump.
Any idea?

L10nRegistry.loadSync = function(uri) {
 let url = null;
  try {
    url = Services.io.newURI(uri);
    if(!url) {
        console.log('error services.io.newURI returned null. uri was: ' + uri);
    }
    let data = Cu.readUTF8URI(url);
    return data;
  } catch (e) {
    if (
      e.result == Cr.NS_ERROR_INVALID_ARG ||
      e.result == Cr.NS_ERROR_NOT_INITIALIZED
    ) {
      try {
        // The preloader doesn't support this url or isn't initialized
        // (xpcshell test). Try a synchronous channel load.
        let stream = NetUtil.newChannel({
          uri,
          loadUsingSystemPrincipal: true,
        }).open();

        return NetUtil.readInputStreamToString(stream, stream.available(), {
          charset: "UTF-8",
        });
      } catch (e) {
        if (e.result != Cr.NS_ERROR_FILE_NOT_FOUND) {
          console.log('url: ' + url + ', uri : ' + uri);
          Cu.reportError(e);
        }
      }
    } else if (e.result != Cr.NS_ERROR_FILE_NOT_FOUND) {
      console.log('url: ' + url + ', uri : ' + uri);
      Cu.reportError(e);
    }
  }

  return false;
};

I am not sure how to unwrap |url| to obtain meaningful string.

Now messengercompose.ftl is in omni.ja. I show ja version (en-US version is there, too.)
localization/ja/messenger/messengercompose/messengercompose.ftl
localization/ja/messenger/openpgp/openpgp.ftl
..

So maybe some mapping of the used |url| and the files inside omni.ja file is broken?

I am attaching the listing of omni.ja content on the local TB copy. 78.4.2 (Windows version) 32-bit in the next post.

This is the file listing inside omni.ja.
LN10nRegistry.jsm has been modified for testing locally.

I notice that all files not recognized have /calendar/ path component. So maybe the mapping for /calendar/subdirectory is missing somewhere?

I also think including console.log() before reporterror() is useful for users to report similar issues in the future.

I have downloaded the Japanese version of TB and am using it, BTW. Not sure if the error I see is specific to Japanese version.
(However, if the Japanese locale version of .ftl file is not found from omni.ja, then probably the same root cause makes it impossible
to find en-US version in omni.ja as well.

I noticed the problem:
According to the screen dump of error console,
the following files are requested as part of
resource:///chrome/ hierarchy.

resource:///chrome/ja/locale/ja/calendar/messenger/messengercompose
resource:///chrome/en-US/locale/en-US/calendar/messenger/messengercompose

But the files in omni.ja are in localiztion/{ja,en-US} hierarchy.

messengercompose.ftl
-rw-rw-rw- 2206 1-Jan-2010 00:00:00 localization/ja/messenger/messengercompose/messengercompose.ftl
-rw-rw-rw- 1984 1-Jan-2010 00:00:00 localization/en-US/messenger/messengercompose/messengercompose.ftl

Also, note there ARE already /chrome/ja/locale and /chrome/en-US/locale hierarchies in omni.ja.

  -rw-rw-rw-       307   1-Jan-2010  00:00:00  chrome/ja/locale/ja/alerts/alert.dtd
  -rw-rw-rw-      1274   1-Jan-2010  00:00:00  chrome/ja/locale/ja/alerts/alert.properties
  -rw-rw-rw-       738   1-Jan-2010  00:00:00  chrome/ja/locale/ja/autoconfig/autoconfig.properties
  -rw-rw-rw-       835   1-Jan-2010  00:00:00  chrome/ja/locale/ja/branding/brand.dtd
  -rw-rw-rw-       313   1-Jan-2010  00:00:00  chrome/ja/locale/ja/branding/brand.properties
  -rw-rw-rw-      2319   1-Jan-2010  00:00:00  chrome/ja/locale/ja/calendar/calendar-alarms.properties
  -rw-rw-rw-       660   1-Jan-2010  00:00:00  chrome/ja/locale/ja/calendar/calendar-event-dialog-attendees.properties
 ...

BUT there are NO calendar/messenger sub-hierarchy beneath it.
Come to think of it, I wonder if "/calendar" path component is quite called for in this case.
Message composition is not part of calendar and the ones in omni.ja are certainly part of
messenger/messengercompose.

This suggests that some type of file path conversion issue during omni.ja creation?

OTHERS

Similar issues exist for the following paths.

Requested directory.
resource:///chrome/ja/locale/ja/calendar/messenger/openpgo/
resource:///chrome/en-US/locale/en-US/calendar/messanger/openpgp/

Instances of openpgp.ftl are actually in the following places.
-rw-rw-rw- 29856 1-Jan-2010 00:00:00 localization/en-US/messenger/openpgp/openpgp.ftl
-rw-rw-rw- 36373 1-Jan-2010 00:00:00 localization/ja/messenger/openpgp/openpgp.ftl

resource:///chrome/ja/locale/ja/calendar/calendar/
resource:///chrome/en-US/locale/en-US/calendar/calendar/
calendar-widgets.ftl
-rw-rw-rw- 504 1-Jan-2010 00:00:00 localization/en-US/calendar/calendar-widgets.ftl
-rw-rw-rw- 665 1-Jan-2010 00:00:00 localization/ja/calendar/calendar-widgets.ftl

resource:///chrome/ja/locale/ja/calendar/messenger/otr/
resource:///chrome/en-US/locale/en-US/messenger/otr/
otr.ftl, otrUI.ftl
-rw-rw-rw- 5854 1-Jan-2010 00:00:00 localization/ja/messenger/otr/otr.ftl
-rw-rw-rw- 4155 1-Jan-2010 00:00:00 localization/ja/messenger/otr/otrUI.ftl

-rw-rw-rw- 4856 1-Jan-2010 00:00:00 localization/en-US/messenger/otr/otr.ftl
-rw-rw-rw- 3727 1-Jan-2010 00:00:00 localization/en-US/messenger/otr/otrUI.ftl

One other thing.

While debugging M-C/C-C TB on linux, I noticed that
Files with *.ftl suffix are not understood as part of valid URI spec. by some code in M-C/C-C.
I wonder if this can be related. I will post another message about .ftl suffix thing.

(Wayne, I tried to reopen the bug, I am not sure if I have the right to do so. If I cannot, maybe I should re-create a new bugzilla. I was struggling with local Windows10 PC keyboard/hardware something going haywire, so maybe my login status was not quite right...)

Re: .ftl suffix file.

Many moons ago, I have forgotten exactly why, but I was bothered by certain errors during |make mozmill| test, and during the tracing of the issues to debug this, I noticed one thing.
SetSpec() call returned failures for many URIs. Obviously there ARE invalid paths passed by codes in |make mozmill| and lately mochitest test programs and presumably in valid run-time codes by mistakes.

So I dumped the paths that caused errors of SetSpec() call in one place.
But then I was not so sure what type of paths cause SetSpec() to return NS_OK.
So Investigated a bit.
*.ftl file paths seem to fail permanently from my analysis. I wonder if this has anything to do with the observation that the errors reported in comment 8 are related to .ftl paths.

To wit, here is a little summary from June this year.

Re: SetSpec() failure with |.ftl| path

I summarised the errors from SetSpec() and dump the paths that are
passed to it during mochitest.
The number on the line is the frequency of occurrences.

I think |DTD/xhtml1-strict.dtd|, |null|, |undefined|, and |moz-icon:| are
indeed invalid specification. Somebody has to confirm this.

But all other errors are paths with |.ftl| ending. This can't be a
simple coincidence. I think the M-C/C-C code is not written to handle
this |.ftl| path very well.

========================================
SetSpec Failures/Successes
========================================

Failure first.

    504 SetSpec failed. : aSpec=branding/brand.ftl
    440 SetSpec failed. : aSpec=messenger/preferences/preferences.ftl
    234 SetSpec failed. : aSpec=calendar/preferences.ftl
    220 SetSpec failed. : aSpec=messenger/preferences/languages.ftl
    220 SetSpec failed. : aSpec=messenger/preferences/fonts.ftl
    140 SetSpec failed. : aSpec=messenger/otr/chat.ftl
     33 SetSpec failed. : aSpec=toolkit/global/resetProfile.ftl
     33 SetSpec failed. : aSpec=toolkit/global/processTypes.ftl
     33 SetSpec failed. : aSpec=toolkit/about/aboutSupport.ftl
     33 SetSpec failed. : aSpec=messenger/aboutSupportMail.ftl
     28 SetSpec failed. : aSpec=toolkit/about/aboutAddons.ftl
     11 SetSpec failed. : aSpec=DTD/xhtml1-strict.dtd
      6 SetSpec failed. : aSpec=null
      5 SetSpec failed. : aSpec=undefined
      5 SetSpec failed. : aSpec=moz-icon://
      3 SetSpec failed. : aSpec=toolkit/about/aboutProfiles.ftl
      3 SetSpec failed. : aSpec=toolkit/about/aboutConfig.ftl
      2 SetSpec failed. : aSpec=moz-icon://chrome://calendar/content/sound.wav?size=16

Success.: First 40 lines

  14844 SetSpec succeeded. : aSpec=about:blank
   7422 SetSpec succeeded. : aSpec=moz-safe-about:blank
    558 SetSpec succeeded. : aSpec=about:preferences
    327 SetSpec succeeded. : aSpec=mailbox://nobody@Local%20Folders/Drafts
    244 SetSpec succeeded. : aSpec=data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABgAAAAYCAYAAADgdz34AAABVUlEQVR42mNgGChgbGzMqm9slqFnbHZLz8TsPwoGioHkQGrItgBsOLrBaFjfxCydbAvgLjc2zQNymZCkmPRMzfOhllwj3wKoK9EMB4PQ0FBmJHmgWtM1eqZmS8m1gEHXxGyLnon5WlzyyGyyLMBmwKgFoxYMPgv+gdjq1ta8YL6elRhU/i+1LDgAY
    240 SetSpec succeeded. : aSpec=data:image/svg+xml;filename=extension.svg;base64,PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0idXRmLTgiPz4KPCEtLSBUaGlzIFNvdXJjZSBDb2RlIEZvcm0gaXMgc3ViamVjdCB0byB0aGUgdGVybXMgb2YgdGhlIE1vemlsbGEgUHVibGljCiAgIC0gTGljZW5zZSwgdi4gMi4wLiBJZiBhIGNvcHkgb2YgdGhlIE1QTC
    157 SetSpec succeeded. : aSpec=mailbox://nobody@Local%20Folders/SummarizationA
    150 SetSpec succeeded. : aSpec=mailbox://nobody@Local%20Folders/DeletionE
    145 SetSpec succeeded. : aSpec=moz-nullprincipal:{44b6cd51-bfa2-4912-8d8c-b670697d49b3}

I only showed the first 10 lines for success.

The summary of protocol part of all the successful SetSpec calls are as follows.
successful protocol list
Not all the protocols are explained in mozilla documentation pages. This is a problm on its own.

  15817  aSpec=about
   7422  aSpec=moz-safe-about
   5055  aSpec=mailbox
   4382  aSpec=moz-nullprincipal
    758  aSpec=data
    586  aSpec=moz-icon
    108  aSpec=mailto
     77  aSpec=moz-storage-calendar
     60  aSpec=view-source
     57  aSpec=mailbox-message
     30  aSpec=smtp
     29  aSpec=page-icon
     24  aSpec=imap
     22  aSpec=addons
     22  aSpec=addbook
     18  aSpec=pop3
     17  aSpec=news
     15  aSpec=moz-memory-calendar
      6  aSpec=predictor
      3  aSpec=javascript
      3  aSpec=http
      1  aSpec=ldap

The patch to dump paths for all the cases with proper failed/succeeded prefix is trivial.
But right now it is invoked only when the call fails.

# HG changeset patch
# User ISHIKAWA, Chiaki <ishikawa@yk.rim.or.jp>
# Parent  f8e3af9ab87255463730e08a419b56b1fa1c1135
dump aSpec(i.e., path) for SetSpec failure

diff --git a/netwerk/base/nsIURIMutator.idl b/netwerk/base/nsIURIMutator.idl
--- a/netwerk/base/nsIURIMutator.idl
+++ b/netwerk/base/nsIURIMutator.idl
@@ -354,16 +354,29 @@ public:
   }
 
   NS_MutateURI& SetSpec(const nsACString& aSpec)
   {
     if (NS_FAILED(mStatus)) {
       return *this;
     }
     mStatus = mMutator->SetSpec(aSpec, nullptr);
+#if DEBUG
+    if (NS_FAILED(mStatus)) {
+      char *l_data;
+      char l_string[256];
+      int len = aSpec.Length();
+      int upper = len > 255 ? 255: len;
+      l_data =  ToNewCString(aSpec);
+      bcopy(l_data, l_string, upper);
+      l_string[upper] = '\0';
+
+      fprintf(stderr,"{debug} SetSpec %s : aSpec=%s\n", NS_FAILED(mStatus) ? "failed." : "succeeded.", l_string);
+    }
+#endif
     return *this;
   }
   NS_MutateURI& SetScheme(const nsACString& aScheme)
   {
     if (NS_FAILED(mStatus)) {
       return *this;
     }
     mStatus = mMutator->SetScheme(aScheme, nullptr);

(Wayne, I tried to reopen the bug, I am not sure if I have the right to do so. If I cannot, maybe I should re-create a new bugzilla. I was struggling with local Windows10 PC keyboard/hardware something going haywire, so maybe my login status was not quite right...)

your account looks fine

(In reply to Wayne Mery (:wsmwk) from comment #18)

(Wayne, I tried to reopen the bug, I am not sure if I have the right to do so. If I cannot, maybe I should re-create a new bugzilla. I was struggling with local Windows10 PC keyboard/hardware something going haywire, so maybe my login status was not quite right...)

your account looks fine

Thank you for the confirmation.

I hope someone can figure out the file conversion issue. I don't see the problem with M-C/C-C TB on my local linux PC. I think that is because it is NOT localized and does not have any L10N string at all?

This is a series of hacks to prevent the NS_ERROR_FILE_UNRECOGNIZED_PATH error. A number of
Services.intl functions throw this error the first time they are called when they load .ftl
files synchronously. Where possible, this patch loads the files asynchronously first and
avoids the error.

The same thing happens in OTRUI.jsm, which should ultimately be fixed to avoid sync L10n.

In some places I've managed to avoid the error by converting the L10n calls to async and/or
delaying the loading of the .ftl file until it is needed.

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/a81e33bf230b
Try to avoid errors from synchronous loading of L10n files. r=mkmelin

Is there a way to test if this is fixed in Thunderbird 85? Please give steps, if needed. Thank you.

On nightly so far. There probably won't be another 85 beta.