in beta 82 and 83 we have some crashes with this signature, which comes via DoExecuteNextTaskOnlyMainThreadInternal

This is my crash report: https://crash-stats.mozilla.org/report/index/d0e790b6-1b98-48b6-ae95-743d10201029

MOZ_CRASH Reason: Invalid principal infos found: baseDomain (aaaa://aaaa.aaaaaa.aaa:DDD/) doesn't match passed one ({aDaDDaaD-aDDa-DDDD-DaDD-DaDDaDaDDDaa})!

Top 10 frames of crashing thread:

0 XUL mozilla::dom::quota:: dom/quota/ActorsParent.cpp:10358
1 XUL JS::ClearKeptObjects js/src/jsapi.cpp:1408
2 SkyLight CGSEventSourceForID 
3 XUL nsJSContext::MaybePokeCC dom/base/nsJSEnvironment.cpp:1895
4 XUL mozilla::RunnableTask::Run xpcom/threads/TaskController.cpp:245
5 XUL mozilla::TaskController::DoExecuteNextTaskOnlyMainThreadInternal xpcom/threads/TaskController.cpp:515
6 XUL mozilla::TaskController::ExecuteNextTaskOnlyMainThreadInternal xpcom/threads/TaskController.cpp:374
7 XUL mozilla::detail::RunnableFunction<mozilla::TaskController::InitializeInternal xpcom/threads/nsThreadUtils.h:577
8 XUL nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1197
9 libmozglue.dylib arena_dalloc memory/build/mozjemalloc.cpp:3377

bp-30b05789-6898-400d-9f7f-7f8bb0201102 is someone using linux

depends on bug 1536596?

IIRC this was something temporary which got fixed on trunk (maybe the m-c offender was uplifted too??)

84 beta bp-e86f4822-6d19-4927-bbc5-965860201120
I had just switched to the addons tab, and typed in "signature", had gotten results screen back, was about to click on one (or did)

(In reply to Magnus Melin [:mkmelin] from comment #2)

IIRC this was something temporary which got fixed on trunk (maybe the m-c offender was uplifted too??)

Still seems to be a thing. I have now crashed with 85 beta bp-7f011215-a2a8-48f9-b268-9bda30201221, so this is my second crash. I had just done tabbed back to Thunderbird (and I don't recall doing anything except maybe clicking a thunderbird tab). Before I tabbed away I had done a global search, and copied some text from an email.

bp-034049a4-bcaf-45d0-9497-cd9320201221 is from someone on nightly

Sorry, no idea.

I just crashed again, this time pretty quickly with the new 85.0b3 bp-5ed2ceeb-50d2-42e2-82f9-e32b40201230

I don't have an explanation, but both 85 beta and 86 nightly crash rate recently increased.
Most crashes are buildid 20201222142912 which would be 85.0b2.
85.0b2 has checkins:

• Bug 1680914 - Shutdown crash in [@ md_UnlockAndPostNotifies] (nss) via ldap_msgdelete (ldap60.dll) use-after-free
• Bug 1664731 - After release 78 some event descriptions and categories are lost when editing a single recurring event

and backout Bug 1683548 - Email with embedded image cannot be sent. "too much recursion MsgComposeCommands.js:4683"

First beta crash buildid 20200924224300 = 82.0b1 build 2. The crash rate perhaps increased with 20200929195155 82.0b2

In contrast, first nightly crash is much later buildid 20201213102700, predating 85.0b2 by a week.

I think this is a different issue than the Firefox issue reported in Bug 1536596, but the diagnostics added there may help to identify the cause of this one.

Here, we have reports showing crash reasons such as Invalid principal infos found: baseDomain (aaaa://aaaa.aaa-aaaaaaaa.aaa:DDD/) doesn't match passed one ({DDaaDDDa-DaaD-DaDD-DDDD-aDDaDaDDDDaa})!, while in the (unresolved) Firefox issue we had Invalid principal infos found: originNoSuffix (file://aaaaaaaaa_aaaa_aaa_aaaaaa) doesn't match passed one (file:///a:/aaaaaaaa/aaaa-aaaaaa/DD-aaaaa-aaaa-aaa-aaaaaaaaaa/)!, the former being file://UNIVERSAL_FILE_URI_ORIGIN without the obfuscation.

Does comment 8 help? (Thanks Simon)

#5 crash for nightly builds

Oof. I can't glean anything from the crash logs (the bp-5ed2ceeb-50d2-42e2-82f9-e32b40201230 one from comment 6 is particularly wild - I suspect that one is a bit of a red herring - the other ones I looked at are much "cleaner" crashes).

Sounds like you can get it to crash reasonably often, Wayne? If we can get a reliable STR then I can try and catch it in the debugger or - more likely, given the message-handling nature of this one - blitz the my local codebase with huge numbers of printfs :- ). Without an STR I guess it'd be a case of trying to add more diagnostics to try and pinpoint where the bad principal info is being set up (that's pretty handwavey - I have almost zero knowledge on how any of this stuff works, but nothing like a good excuse to learn!).

Ben, I can reproduce this on Mac with my production profile using 86.0b1 build1 by using -offline https://crash-stats.mozilla.org/report/index/c5a13360-42a7-4349-95a0-942ef0210126#tab-bugzilla

... and also in safe mode https://crash-stats.mozilla.org/report/index/6a91536b-ada4-4824-889f-636b40210126

When I do not use -offline and promptly reply to the primary password prompt, then startup hangs.

If I let the prompt sit for 20-30 seconds, then give the password, then I get this same crash signature https://crash-stats.mozilla.org/report/index/c93e66b5-761c-4ee7-956a-6e4e80210126#tab-details

Might be Mac only. And might become a blocker for beta.

In a new profile I do NOT crash.

from Mac terminal

I suppose the aaaa://aaaa.aaaaaa.aaa:DDD is imap://mail.lehigh.edu:993?
Other than that, not much clue.

build2 of 86.0b1 also hangs for me on Mac. Not successful determining whether a pref affects it.

I got to retesting 86.0b1.

• e10s disabled fully - no crashes - browser.tabs.remote.autostart and extensions.webextensions.remote both false
• browser.tabs.remote.autostart true - TB crashes on startup bp-9a004243-bc47-4357-aa03-d2ac20210129
• extensions.webextensions.remote true - crashes when clicking crash report link in troubleshooting bp-15e976c7-3855-4cc8-935d-6a5280210129, or add-on website link in tools > addons bp-fbf87ced-59df-45de-9ba3-9c18e0210129

So far crash-stats has 8 reports. The 6 Mac reports might be all me. And there are two windows crashes, both from the same person.

I can also reliably crash with e10s fully disabled - a crash report page open in a thunderbird tab, and clicking on the "more reports" link. bp-e6040baa-9bb5-44e4-953f-ad2ed0210129

Doesn't happen on my old Windows 10 work PC with an existing (but small) profile.

bp-b98b906a-1ae8-457a-8825-7f6c60210130 on Mac clicking on an RSS message with e10s disabled - browser.tabs.remote.autostart and extensions.webextensions.remote both false. reproducible. (clicking on rss folder and getting rss messages does not crash)

I combed through config editor, and couldn't find any settings that might explain my Mac crashes.

Perhaps there is more than e10s involved, but it somehow clearly is involved - bug 1646648

solildly #3 crash for beta.

clicking on a blog post this time - 86.0b1, e10s disabled fully - no crashes - browser.tabs.remote.autostart and extensions.webextensions.remote both false bp-a7776f71-eab4-4ea1-b28d-458610210203

There may be related signatures. When accessing an RSS posting I just crashed twice with mozilla::detail::MutexImpl::unlock | arena_t::DallocSmall | arena_dalloc | nsCOMArray_base::RemoveObjectAt bp-87686da6-5454-4211-9ece-808660210209 and bp-877e248f-37a4-437e-9dbe-bb8d90210209

different signature this time, using 87 beta
XUL@0x2466c93 | XUL@0x5c8075f | libnss3.dylib@0x7d43
bp-dffc653a-7cbd-48e2-97e6-83b350210227

I don't know if this is a definitive trigger, but I had rss.max_concurrent_feeds set to 25. I deleted the preference and now do not crash.
But, according to KB articles, 25 is the default

Turns out, deleting the preference is not a complete cure. With 87 beta

• XUL@0x2466c93 | XUL@0x5c8075f | CFRunLoopWakeUp bp-42ad646f-fd77-4160-bd33-056a80210228 rss.max_concurrent_feeds set to 12
• XUL@0x2466c93 | XUL@0x5c8075f | CFRunLoopWakeUp bp-965c77b3-8ec0-499b-b31d-7e87c0210228 rss.max_concurrent_feeds was deleted

And, per comment 16, clicking "more reports" still crashes
XUL@0x2466c93 | XUL@0x5c8075f bp-28169854-3f95-4777-ad52-b0b850210228

Not sure what preference to tweak next

Crash rate peaked around Feb 9 - stats suggest 20-30 users were affected - and then dropped [1] such that only one user crashed with the original signature mozilla::dom::quota::(anonymous namespace)::PrincipalVerifier::Run in the past week. So no longer a topcrash.

Just tried nightly using the beta profile - it also crashes. Perhaps this stack will be of more use than previous stacks. Nightly in new profile does not crash.
bp-31b0a4b5-d4d4-42db-816f-b040f0210228 [@ XUL@0x2662419 | XUL@0x109ebe | XUL@0x108b68 | XUL@0x107ba5 | XUL@0x10bc85 | XUL@0x116dc1 | XUL@0x115111 | XUL@0x2be36a0 | XUL@0x2c4e690 | CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION ]

[1] https://crash-stats.mozilla.org/signature/?version=87.0a1&version=86.0esr&version=86.0&product=Thunderbird&signature=mozilla%3A%3Adom%3A%3Aquota%3A%3A%28anonymous%20namespace%29%3A%3APrincipalVerifier%3A%3ARun&date=%3E%3D2020-11-28T17%3A12%3A00.000Z&date=%3C2021-02-28T17%3A12%3A00.000Z&_columns=date&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=reason&_columns=address&_columns=install_time&_columns=startup_crash&_sort=-date&_sort=version&_sort=-build_id&page=1#graphs

2020-09-25 nightly crashes mozilla::dom::quota::(anonymous namespace)::PrincipalVerifier::Run bp-36d9be20-b372-4903-926a-eddd70210228
2020-08-04 81.0a1 crashes
2020-07-03 80.0a1 crashes mozilla::dom::quota::(anonymous namespace)::PrincipalVerifier::Run bp-d016fe39-1e61-41fd-98bc-51c400210228

Now every startup of 87 beta crashes with the likes of these, even after deleting session.json and safe mode

• XUL@0x2466c93 | XUL@0x5c8075f | vDSP_vsmfixu24 bp-93c14a13-cfab-4085-99d5-d5efa0210228
• XUL@0x2466c93 | XUL@0x5c8075f | XUL@0x6c85c5 | XUL@0x5c8075f | XUL@0x5c8075f | XUL@0xfeedd | XUL@0xfdf1f | XUL@0xfd181 | XUL@0x100951 | XUL@0x10ae34 | -[__NSArrayM removeObjectsInRange:] bp-bfe241fd-857c-43ee-8da2-820f30210228

Startup crash is gone after going restoring a backup of my profile

preview pane closed, select RSS article, enable preview, crash
bp-cff95c5a-f281-49b7-bd7a-259810210228 XUL@0x2466c93 | XUL@0x5c8075f | libmozglue.dylib@0x9b7b

No clues. But appears very rare now with only 0-3 crashes per day.

(In reply to Ben Campbell from comment #10)

...
Sounds like you can get it to crash reasonably often, Wayne?

Yes. And I had forgotten searching in add-ons causes crash - see steps in bug 1671925.

If we can get a reliable STR then I can try and catch it in the debugger or - more likely, given the message-handling nature of this one - blitz the my local codebase with huge numbers of printfs :- ). Without an STR I guess it'd be a case of trying to add more diagnostics to try and pinpoint where the bad principal info is being set up (that's pretty handwavey - I have almost zero knowledge on how any of this stuff works, but nothing like a good excuse to learn!).

If you aren't able to reproduce, please shoot me a build with printfs

(In reply to Simon Giesecke [:sg] [he/him] from comment #8)

I think this is a different issue than the Firefox issue reported in Bug 1536596, but the diagnostics added there may help to identify the cause of this one.

Here, we have reports showing crash reasons such as Invalid principal infos found: baseDomain (aaaa://aaaa.aaa-aaaaaaaa.aaa:DDD/) doesn't match passed one ({DDaaDDDa-DaaD-DaDD-DDDD-aDDaDaDDDDaa})!, while in the (unresolved) Firefox issue we had Invalid principal infos found: originNoSuffix (file://aaaaaaaaa_aaaa_aaa_aaaaaa) doesn't match passed one (file:///a:/aaaaaaaa/aaaa-aaaaaa/DD-aaaaa-aaaa-aaa-aaaaaaaaaa/)!, the former being file://UNIVERSAL_FILE_URI_ORIGIN without the obfuscation.

Does bug 1536596 comment 44 help?

As noted earlier, crashes only if browser.tabs.remote.autostart and extensions.webextensions.remote are true

to go with the console bp-dd33daad-1f67-4fb2-8a64-712590210413

bp-a3fe358f-3c91-4cb1-be72-17e310210504 89.0b2 very shortly after startup.
I had just clicked a folder which was still receiving new messages via filter.

Unlike comment 32, both browser.tabs.remote.autostart and extensions.webextensions.remote are false

bp-3028b5de-9eb7-48c6-9f35-24eb60210518 on the Mac, unattended

In the failures, the baseDomain being checked looks like a UUID. So I'd guess some uri somewhere is borking it up somehow. Seeing the bad baseDomain and the better-formed one it's being checked against would probably help a lot. In the uploaded crash reports they are anonymized.
But the non-anonymized ones are logged locally via QM_WARNING, which calls NS_WARNING() with the message, and also logs it to the (javascript?) console. So I'd imagine it would show up via stdout in debug builds at least... Not quite sure how easy it is to get at stdout on Mac TB builds, but if you can catch the non-anonymized message, that'd probably help a lot! (especially if the UUID appears in greppable form somewhere in the codebase!)
If not, let me know, and we'll work out some hack to log it to it's own file or something silly like that (fopen("/tmp/blah.txt"), fprintf(msg), fflush(), fclose() etc...)

Ben, I am crashing once a week on average, so I should be able to get something. But I'll need a debug build - can get me one for beta? Also, which aspect of bug 1689130 would most help us?

Anthony, can you tell me what's needed for comment 36? And would we need the hack mentioned in the last sentence?

Reply to Wayne's request Comment 37!

Been trying to work out what the issue is and so reproduce - if related to rss feeds, I do not use them (actually thought these died years ago!!!)

In truth, Wayne, this stuff in Ben's comment a bit out of my field, sorry. I am mainly a hardware techie - if you decode for me I will see what I can do for you

Macbook using TB beta. I was not at keyboard. Was sitting in Drafts folder of wsm0 imap account, new html mail came in from surveymonkey "Reminder: We want your opinion".
bp-90ab5997-bc5e-4dc8-951e-aac180210610

(In reply to Antony from comment #38)

Reply to Wayne's request Comment 37!
...
In truth, Wayne, this stuff in Ben's comment a bit out of my field, sorry. I am mainly a hardware techie - if you decode for me I will see what I can do for you

Sorry, I think I meant to NI Ben and CC you.

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

Ben, I am crashing once a week on average, so I should be able to get something. But I'll need a debug build - can get me one for beta? Also, which aspect of bug 1689130 would most help us?

I don't think a special build is required - the non-anonymized UUID is being output by NS_WARNING, so it should appear in stdout in debug builds as they already are (assuming debug builds are available somewhere? I can kick off a try build if that's any use...).
The only thing is that I don't quite know how you get at stdout output if you're running it as a mac .app bundle (which is how I assume it comes packaged)... A bit of a guess, but I think you can open a terminal and cd into the thunderbird.app dir and run the binary directly and it should all magically work, right?

This works for me:

/Applications/Thunderbird.app/Contents/MacOS/thunderbird

Unfortunately my crash rate has dropped - I haven't crashed now in 10 days, and the crash prior to that was 21 days.

Ben, I've captured a couple crashes with debug build. It crashes even with
user_pref("browser.tabs.remote.autostart", false);

Larger Mac terminal log

Also

• debug build crashes also in safe mode
• crashes immediately after providing primary password - not before

Annoyingly, the logs you posted (comment 44, comment 45) don't include the error message I was hoping for :-(
From a bit of searching, I think mac apps have their stdout and stderr directed to /dev/null these days. Which doesn't help us at all.
The only workaround I know of is to run it from the commandline, using the terminal (as Calum does in comment 41). But I can imagine it'd be rather an arse to run your day-to-day email like that...

The reason I want the stderr is that the warning prints out the non-anonymised url there (ultimately via NS_DebugBreak).
And if I can see that message, I'll know what protocol to be looking in (Although IMAP is usually a safe bet if anything goes wrong :-).

The anonymised version of the message we see in the crash report is:

Invalid principal infos found: baseDomain (aaaa://aaaa.aaaaaa.aaa:DDD/) doesn't match passed one ({DaDDDaaD-DaDD-DDDD-aDDD-aDaDaDaaDDDD})!

The anonymisation replaces alphabetical characters with 'a' and digits with 'D'. So the baseDomain passed in looks like a GUID, which seems rather wrong...

According to https://support.apple.com/guide/terminal/redirect-terminal-input-and-output-apd1dbe647b-7e11-49dc-aa76-89aa7e53ce36/mac we should be seeing stdout and stderr. "By default, errors are displayed on the command line along with standard output.".

The logs I uploaded were obtained by running from terminal. But that was running thunderbird-bin

Is this better?

2021-07-22 01:07:54.292844 UTC - [Parent 81385: Main Thread]: D/nsHttp nsHttpHandler::NotifyObservers [chan=14d0a8280 event="document-on-opening-request"]
IPDL protocol error: Handler returned error code!

###!!! [Parent][DispatchAsyncMessage] Error: PClientManager::Msg_ExpectFutureClientSource Processing error: message was deserialized, but the handler returned false (indicating failure)

2021-07-22 01:07:54.309962 UTC - [Parent 81385: Main Thread]: D/nsStreamPump nsInputStreamPump::OnInputStreamReady [this=14e0e4530]
2021-07-22 01:07:54.309992 UTC - [Parent 81385: Main Thread]: D/nsStreamPump OnStateStart [this=14e0e4530]
2021-07-22 01:07:54.310008 UTC - [Parent 81385: Main Thread]: V/nsHttp ParentChannelListener::OnStartRequest [this=14c7bbe80]
2021-07-22 01:07:54.312317 UTC - [Parent 81385: Main Thread]: D/nsStreamPump OnStateTransfer [this=14e0e4530]
2021-07-22 01:07:54.312355 UTC - [Parent 81385: Main Thread]: D/nsStreamPump Available returned [stream=14a3e3160 rv=0 avail=786432]
2021-07-22 01:07:54.312364 UTC - [Parent 81385: Main Thread]: D/nsStreamPump calling OnDataAvailable [offset=0 count=786432(786432)]
2021-07-22 01:07:54.312371 UTC - [Parent 81385: Main Thread]: V/nsHttp ParentChannelListener::OnDataAvailable [this=14c7bbe80]
IPDL protocol error: Handler returned error code!

###!!! [Parent][DispatchAsyncMessage] Error: PClientManager::Msg_ForgetFutureClientSource Processing error: message was deserialized, but the handler returned false (indicating failure)

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

Is this better?

Hmm, sorry, I'm still stumped here. The logs don't show the Invalid principal infos found: ... message I was hoping for.
Actually they look like a different crash altogether... although that could just be downstream consequences of the bad baseDomain.
I'm kind of out of ideas on this now :-(

Crashed just after updating to 92 beta on Mac, doing nothing https://crash-stats.mozilla.org/report/index/01ef9332-7eec-4a92-b004-14ec30210812

Still very rare across the user base, only 20 crashes in past month. But (fortunately?) not only me https://crash-stats.mozilla.org/signature/?signature=mozilla%3A%3Adom%3A%3Aquota%3A%3A%28anonymous%20namespace%29%3A%3APrincipalVerifier%3A%3ARun&product=Thunderbird&date=%3E%3D2021-07-12T15%3A45%3A00.000Z&date=%3C2021-08-12T15%3A45%3A00.000Z&_sort=-date

Copied from the DUP:

Actual results:

When TB starts, a tab is opened which seems to access some webpage (?) ... but before it's done, or perhaps right when it's done - which happens within a second or so - Thunderbird crashes.

Some of the crashes:

URL: https://crash-stats.mozilla.org/report/index/f441485e-d322-4b8f-8c2e-1bd180210828

and codes for a bunch of them:
bp-f441485e-d322-4b8f-8c2e-1bd180210828
bp-a833934a-38e3-46dc-b704-a8d180210828
bp-e363457d-1e44-4cb9-9e72-f97710210828
bp-a29ce279-6115-4ac6-99f1-b87f60210828
bp-aebca477-fcc8-4f3f-a6e0-032d30210828
bp-aef07ac4-defe-474d-8dee-790590210828
bp-530746e3-4506-48e1-95c7-d3a940210828
bp-4e3e578c-e152-4851-8ee9-e0c5d0210828

Continued comment regarding the dupe: These crashes happen when Owl is enabled and an Exchange account is configured; and if Owl is disabled, that extra tab causing the crash is not opened. I can also circumvent the crash by quickly closing the tab right after it has opened (under a second of grace...)

To clarify: Owl opens a tab (which accesses some web-based API); and TB, or even Mozilla core code, crashes when trying to display the content of that tab. So it's not Owl itself that crashes.

alilendu: The crash is triggered by your email server's login webpage, which crashes TB, probably while trying to save information using IndexedDB or similar APIs.

That is quite possible, but - the email server is outlook.office365.com , i.e. not something obscure and uncommon.

As I've explained to you elsewhere, Office365 works fine for me and for most users. There must be some other factor at play that causes the crash. That said, it's not going to be very helpful to discuss this further, until some developer looks into the crash signature. It might be obvious when looking at the code. Further discussion is likely to be distracting, so please don't.

This is the code that's crashing:

https://searchfox.org/mozilla-central/source/dom/quota/ActorsParent.cpp#9641

#ifdef QM_PRINCIPALINFO_VERIFICATION_ENABLED
...
NS_IMETHODIMP PrincipalVerifier::Run() {
  MOZ_ASSERT(NS_IsMainThread());

  nsAutoCString allDetails;
  for (auto& principalInfo : mPrincipalInfos) {
    const auto res = CheckPrincipalInfoValidity(principalInfo);
    if (res.isErr()) {
      if (!allDetails.IsEmpty()) {
        allDetails.AppendLiteral(", ");
      }

      allDetails.Append(res.inspectErr());
    }
  }

  if (!allDetails.IsEmpty()) {
    allDetails.Insert("Invalid principal infos found: ", 0);

    // In case of invalid principal infos, this will produce a crash reason such
    // as:
    //   Invalid principal infos found: originNoSuffix (https://aaa.aaaaaaa.aaa)
    //   doesn't match passed one (about:aaaa)!
    //
    // In case of errors while validating a principal, it will contain a
    // different message describing that error, which does not contain any
    // details of the actual principal info at the moment.
    //
    // This string will be leaked.
    MOZ_CRASH_UNSAFE(strdup(allDetails.BeginReading()));
  }

  return NS_OK;
}

#endif

With https://addons.thunderbird.net/en-US/thunderbird/addon/quotecolors/ version 3.0.2 installed, I crash when using 93.0b1. 92.0b5 was not crashing.
bp-6bf85167-239b-4212-94ad-b736f0210908

Walt, can you reproduce this?

Not getting a crash here with that extension installed in 93.0b1 on Windows 10 and Fedora 34.

Crash on Mac last night, again unattended bp-e1e5b26f-0b58-4a71-830b-6a96c0210915 94.0a1 (aleca's try build)

Crashed twice 94.0b1:

• enabling quotecolors addon bp-ac934ac0-3674-408f-b409-e3b2f0211008
• updating quotecolors addon bp-c1e90f8b-2963-4ece-a25e-22ec30211008

Startup crash 94.0b2 on Mac bp-6ee9e6cd-0906-4bc6-af09-b1e040211009 with quotecolors addon enabled.
Startup with quotecolors disabled - no crash

I'm out of bullets. Maybe Ben and I do an online session together?

The blocker I set, bug 1536596, has been marked not actionable.

Ben, Magnus,

Have you seen bug 1536596 comment 51 which references Bug 1665056 - The "security.fileuri.strict_origin_policy" pref should be latched at startup and not updated because it causes cross-process principal inconsistencies

I had just crashed on Mac attempting to "Download more dictionaries" from Settings https://crash-stats.thunderbird.net/report/bp-f27d55a9-afa2-4305-985d-d2ca91220121#tab-details

While it's possible something there could help, I do suspect bug bug 1536596 comment 48 is right: it's just Thunderbird doing something wrong wrt IMAP URIs or principals.

(In reply to Magnus Melin [:mkmelin] from comment #65)

While it's possible something there could help, I do suspect bug bug 1536596 comment 48 is right: it's just Thunderbird doing something wrong wrt IMAP URIs or principals.

"The crash reason there (requires the bits to see private crash data and is sanitized with alpha/digit collapse to a/D), however, is interesting (the baseDomain is for what is certainly an IMAP message URI, but the passed one is clearly for a null principal GUID) but is likely specifically down to Thunderbird's message display logic which does not generalize to Firefox because it's likely just Thunderbird violating invariants.

There are a few crashes from Firefox, but they all seem to be the potentially expected case where the expected originNoSuffix is (sanitized) file://UNIVERSAL_FILE_URI_ORIGIN but what was received is the (sanitized) specific file path, indicating the pref inconsistency discussed above.'"

So bug 1749276 may be related. Hopefully we will make progress there.

Perhaps a a different question - Bug 1730535 will not become a problem?

• 98.0b1 on Mac, every (non-safe mode) startup is a crash https://crash-stats.thunderbird.net/report/bp-6a9d337c-934d-4bbf-8b91-bc9211220209
• Disabled all addons and started not in safe mode, still crashes.
  quickmove@mozilla.kewis.ch 1.10.0
  restartButton@dillinger 1.3
  compactHeaders@dillinger 2.21
  plik@johannes-endres.de 1.2.2
  send@tealdulcet.com 1.1

10 crashes so far

signature for crashes with addons, on Mac, is now EMPTY: no crashing thread identified; MissingThreadList bp-23b2c139-de05-41a7-b7e4-8e9b20220430

NOTE

I just (re)discovered (after crashing bp-54ddcb24-3958-4d66-9eaf-981ee0220514) that
a) extensions.webextensions.remote set to false is ineffective - more troubleshooting info shows that there is a remote process for "Web Content
b) safe mode also doesn't impact these settings

Further, I believe I read somewhere recently that Firefox intends to prevent disabling e10s. This might have implications for us in Thunderbird.

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

a) extensions.webextensions.remote set to false is ineffective - more troubleshooting info shows that there is a remote process for "Web Content

The extensions process(es) are a separate line in the Remote Processes table. The preference won't affect the web content process(es).

Further, I believe I read somewhere recently that Firefox intends to prevent disabling e10s. This might have implications for us in Thunderbird.

They probably do, in fact I'm surprised it hasn't happened already. We're just going to have to learn to live with it.

FWIW I changed security.fileuri.strict_origin_policy -> false and my crashes continue

I discovered foldercache.json contains references to my current Thunderbird profile /users/wayne_1/, and my past Thunderbird profile which was copied from a different Mac account /users/wayne/.

bp-2583a2ee-f3be-4552-8402-d8e910220905 happened while I had filter log dialog open

bp-31add330-865f-4109-b189-badc00221216 just idle. 109.0b1

I haven't had THIS crash since a month ago bp-207dbaad-c24a-4846-bd48-fa87a0230131 110.0b2. I had a lot of these crashes at the end of January.

Currently on 111 beta. I can now do add-ons. It might be interesting to go back to an earlier version of Thunderbird to see if it crashes.

I jinxed myself with comment 75. 112.0b1 is crashing like a rock, even in safe mode bp-dd9f4945-0509-4278-a61c-b49a90230315

Oddly enough, after a hang I had with 110.b3 during shutdown, just prior to installing 112 shutdownhang | mozilla::SpinEventLoopUntil<T> | nsThread::Shutdown | nsThreadManager::ShutdownNonMainThreads bp-360a2e9-9408-4dd9-9b0a-fcef40230315

It is interesting that release builds have zero crashes - it's all nightly and beta

Is it a coincidence that to 112 we uplifted Bug 1821947 - Start page doesn't appear at start-up ?

Dunno. Works for me. Have you tried disabling the start page using prefs.js?

It's more likely to be bug 1821234 but that's a wild guess.

Instantly, I was able to start without trouble after editing prefs.js to include

user_pref("mailnews.start_page.url", "about:blank");

bp-dd7136e2-93a4-47a6-b314-babdf0230315 happened shortly after I replied to an email
bp-4ba92421-ea48-4d08-959f-306850230315 happened trying to install an addon

I don't have much to add, but seems confirmed your case is related to bug 1821234.

Among windows crashes, many have installed en-AU@dictionaries.addons.mozilla.org English (Australian) Dictionary 2.2.1webext
bp-39f1cafc-cf3d-4559-8c2c-dd9c40230318
https://crash-stats.mozilla.org/signature/?product=Thunderbird&platform=Windows&addons=%21~en-AU&signature=mozilla%3A%3Adom%3A%3Aquota%3A%3A%28anonymous%20namespace%29%3A%3APrincipalVerifier%3A%3ARun&date=%3E%3D2022-09-25T00%3A00%3A00.000Z&date=%3C2023-03-25T23%3A59%3A00.000Z&_columns=date&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=reason&_columns=address&_columns=install_time&_columns=startup_crash&_sort=-date&page=1

Perhaps there is hope in Bug 1810412 - Get rid of PrincipalVerifier

Is bug 1810412 and its blockers likely to force us to make any code adjustments?

(In reply to Magnus Melin [:mkmelin] from comment #81)

I don't have much to add, but seems confirmed your case is related to bug 1821234.

bug 1821234 hasn't helped me at all, afaict.

Another way to cause the crash:

• click manage on an addon (for example Rob's Markdown Here Revival)
• click the link to author

Tested 113 beta in a new profile - doesn't crash in new profile. Still not finding which pref is related
browser.tabs.remote.autostart -> false
security.fileuri.strict_origin_policy -> false
browser.cache.disk.smart_size.enabled -> false

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

Is bug 1810412 and its blockers likely to force us to make any code adjustments?

Probably not?

113.0b5 (from last Wednesday) is not crashing for me, despite no changes in any block bugs or related bugs.
I downgraded to 113.0b3 and it crashes. I have not yet tested 113.0b4.

I do not see any obvious comm-beta checkins in pushlog that would affected this. Will do more checking before closing this.

No crashes on crash-stats since 113.0b3