enigmail - JavaScript Error: "NS_ERROR_FACTORY_NOT_REGISTERED: Component returned failure code: 0x80040154 (NS_ERROR_FACTORY_NOT_REGISTERED) [nsIMessenger.messageServiceFromURI]" {file: "chrome://openpgp/content/ui/enigmailMsgComposeOverlay.js" line: 483}
Categories
(Thunderbird :: Message Compose Window, defect)
Tracking
(Not tracked)
People
(Reporter: ishikawa, Assigned: KaiE)
References
Details
Attachments
(1 file, 1 obsolete file)
Recently I noticed the following errors in the local mochitest log of FULL DEBUG version of Thunderbird.
This started to appear at the end of April.
I don't see it in my log dated April 20.
But they were in the log dated April 28 and still persist.
They seem to be related to enigmail/openpgp.
82:56.39 TEST_START: comm/mail/test/browser/composition/browser_forwardRFC822Attach.js
82:56.40 INFO Entering test bound setupModule
82:56.40 INFO Leaving test bound setupModule
82:56.40 INFO Entering test bound test_forwarding_long_html_line_as_attachment
83:00.16 GECKO(1455535) [1455535, Main Thread] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80040154 (NS_ERROR_FACTORY_NOT_REGISTERED): file /NEW-SSD/NREF-COMM-CENTRAL/mozilla/comm/mailnews/base/util/nsMsgUtils.cpp, line 304
83:00.17 GECKO(1455535) JavaScript error: chrome://openpgp/content/ui/enigmailMsgComposeOverlay.js, line 483: NS_ERROR_FACTORY_NOT_REGISTERED: Component returned failure code: 0x80040154 (NS_ERROR_FACTORY_NOT_REGISTERED) [nsIMessenger.messageServiceFromURI]
83:00.29 INFO Console message: [JavaScript Error: "NS_ERROR_FACTORY_NOT_REGISTERED: Component returned failure code: 0x80040154 (NS_ERROR_FACTORY_NOT_REGISTERED) [nsIMessenger.messageServiceFromURI]" {file: "chrome://openpgp/content/ui/enigmailMsgComposeOverlay.js" line: 483}]
83:03.31 INFO Leaving test bound test_forwarding_long_html_line_as_attachment
83:03.31 INFO Entering test bound test_forwarding_feed_message_as_attachment
83:06.95 GECKO(1455535) [1455535, Main Thread] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80040154 (NS_ERROR_FACTORY_NOT_REGISTERED): file /NEW-SSD/NREF-COMM-CENTRAL/mozilla/comm/mailnews/base/util/nsMsgUtils.cpp, line 304
83:06.95 GECKO(1455535) JavaScript error: chrome://openpgp/content/ui/enigmailMsgComposeOverlay.js, line 483: NS_ERROR_FACTORY_NOT_REGISTERED: Component returned failure code: 0x80040154 (NS_ERROR_FACTORY_NOT_REGISTERED) [nsIMessenger.messageServiceFromURI]
83:07.07 INFO Console message: [JavaScript Error: "NS_ERROR_FACTORY_NOT_REGISTERED: Component returned failure code: 0x80040154 (NS_ERROR_FACTORY_NOT_REGISTERED) [nsIMessenger.messageServiceFromURI]" {file: "chrome://openpgp/content/ui/enigmailMsgComposeOverlay.js" line: 483}]
83:10.02 INFO Leaving test bound test_forwarding_feed_message_as_attachment
83:10.19 TEST_END: Test OK. Subtests passed 4/5. Unexpected 0
83:10.19 TEST_START: comm/mail/test/browser/composition/browser_forwardUTF8.js
|
Reporter | |
Updated•5 years ago
|
|
||
Updated•5 years ago
|
|
Assignee | |
Comment 1•5 years ago
|
||
Is this seen on comm-central? I've been focusing on comm-esr78 and haven't built c-c in a while.
Possible related to :jcranmer's recent changes?
|
|
Reporter | |
Comment 2•5 years ago
|
||
(In reply to Kai Engert (:KaiE:) from comment #1)
Is this seen on comm-central? I've been focusing on comm-esr78 and haven't built c-c in a while.
Possible related to :jcranmer's recent changes?
It was reported against C-C four months ago.
At this moment, I cannot build and check locally due to the local patches broken due directory structure changes.
|
|
Assignee | |
Comment 3•5 years ago
|
||
The same exception was triggered today through some other code, see bug 1650551.
I've analyzed what's happening.
It happens during this call in function getMsgHdr,
messenger.messageServiceFromURI(msgUri).messageURIToMsgHdr(msgUri)
and in particular in messageServiceFromURI.
On trunk, when executing mochitests, in several scenarios the msgUri is a file:// URI without any additional query parameters, like this one:
file:///home/user/moz/commcent/obj-thunder-opt/_tests/testing/mochitest/browser/comm/mail/test/browser/composition/data/testmsg.eml
In nsMsgUtils.cpp GetMessageServiceContractIDForURI(), there is special handling for the "file" protocol. If uri has the "file" protocol, and in addition there is a query parameter "application/x-message-display", then the code will use protocol "mailbox" instead.
In the above scenario, there is no query parameter. Consequently the protocol remains at "file". Then a contract ID is constructed, in this scenario "@mozilla.org/messenger/messageservice;1?type=file".
Next, function GetMessageServiceFromURI calls do_GetService on that contract ID - and fails.
On comm-esr78, we never run into that scenario. In my tracing of the mochitest scenarios from bug 1650551, whenever we have a "file" protocol uri, the query parameter "type=application/x-message-display" is present. This causes the "type=mailbox" contract ID to be used, and getService succeeds.
The question is:
What has changed after comm-esr78 on comm-central, that causes file URIs to have no "type=application/x-message-display" query parameter?
|
|
Reporter | |
Comment 5•5 years ago
•
|
||
(In reply to Kai Engert (:KaiE:) from comment #4)
Who might know the answer to comment 3 ?
I throw in another question/comment here.
Many months (a few years) ago, I noticed strange errors dumped from SetSpec() call.
Some URIs that were passed to it were not acceptable, it complained.
But TB chugged along.
I believe I entered a bugzilla about it, but unfortunately,
somehow the error message dump code was removed. Basically it was hidden under the rug.
And I cannot find the bugzilla easily.
I doubt the wisdom of removing it.
Anyway, I have maintained the following local patch to dump the error of SetSpec() in one place for my local testing.
That logging is done very aptly in a file called nsIURIMutator.idl.
This URI mutation and what protocols are valid and what are not should be documented clearly for TB maintenance.
I used to log the SUCCESS case as well in my local dump because I could not figure out what "protocol" are accepted by TB (and presumably FF, but FF does not need to grok pop3, imap, mailbox, etc.).
Here is the patch to log only the failed case. There is a protection that protects the code from an arbitrarily long data. (That is why we see a large data or URI cut short in a log I am about to upload.)
# 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);
The following is the list of failures logged on June 6 2020. Obviously there are bad callers who forget to attach appropriate "protocol". But the error is basically ignored by TB and SOMETHING is done subsequently.
I have a serious doubt if I should trust a mailer whose code does this underneath. But since I have been using TB for a long time, I wish I get rid of such errors and dubious behavior once for all. (Unfortuantely, since TB SEEMS TO WORK FOR ME (famous last words), I have not gotten around to fixing these.
The list also shows the protocols used for successful call. I wish they are all documented clearly.
========================================
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
The following is the successful protocol list:
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
Maybe the person who can answer the question comment 3 can comment on the general framework of URI handling.
(I notice that file: protocol is not in the list above. Maybe I should throw a wider net and check the return code for every call site of |SetSpec| call
during a local mochitest.)
The full list of successful URI during a local mochitest run is uploaded next.
There are many instances of "type=application/x-message-display&number=0" in the list such as
2 SetSpec succeeded. : aSpec=mailbox:///NEW-SSD/moz-obj-dir/objdir-tb3/_tests/testing/mochitest/browser/comm/mail/test/browser/attachment/data/bug1358565.eml?type=application/x-message-display&number=0
|
|
Reporter | |
Comment 6•5 years ago
|
||
The summary of logged |aSpec| to |SetSpec()| in etwerk/base/nsIURIMutator.idl.
The summary is in the descending order of the appearance in the log.
|
|
Assignee | |
Comment 7•5 years ago
|
||
(In reply to Kai Engert (:KaiE:) from comment #4)
Who might know the answer to comment 3 ?
|
||
Comment 8•5 years ago
|
||
I don't recall any recent changes in this area, and since this case was seen already 4 months ago, I think it's likely not directly about a recent change.
|
|
Reporter | |
Comment 9•5 years ago
|
||
Kai,
Does the error in https://bugzilla.mozilla.org/show_bug.cgi?id=1673288#c9
ring a bell?
|
|
||
Comment 11•2 years ago
|
||
To avoid the exception, getOriginalMsgUri() could be changed along the lines of
} else if (gMsgCompose.originalMsgURI) {
// original message is a "true" mail
- msgUri = gMsgCompose.originalMsgURI;
+ msgUri = gMsgCompose.originalMsgURI + "?type=application/x-message-display";
}
return msgUri;
But no hdr would be got for a file:/// message
|
|
Assignee | |
Comment 12•2 years ago
|
||
Ok, I think I understand what's going on.
The exception happens if we are replying in a standalone message window that has loaded the message from a file.
In this scenario, there is no related message header database.
I'm hoping this is the only scenario where this happens.
I don't know how to distinguish this scenario from other scenarios.
Function getMsgHdr() gets called twice in the above scenario.
The first time, the URI is file:// which is unambiguous.
However, in the second call it is mailbox://file.eml?number=0
I don't know if mailbox:// means it was a file, or if mailbox:// could refer to a Thunderbird mail folder.
I suggest we silently ignore this failure.
However, if anyone knows how to clearly distinguish the above scenario, we could continue to log the exception in the other scenarios.
|
|
Assignee | |
Comment 13•2 years ago
|
||
|
||
Updated•2 years ago
|
|
|
Assignee | |
Comment 14•2 years ago
|
||
I cannot reproduce on latest c-c.
|
|
||
Updated•2 years ago
|
|
|
||
Updated•2 years ago
|
Description
•