Stack trace:

JavaScript error: resource://gre/modules/SessionStoreFunctions.jsm, line 106: NS_ERROR_FILE_NOT_FOUND:
 0:21.40 INFO Console message: [JavaScript Error: "NS_ERROR_FILE_NOT_FOUND: " {file: "resource://gre/modules/SessionStoreFunctions.jsm" line: 106}]
SSF_updateSessionStoreForWindow@resource://gre/modules/SessionStoreFunctions.jsm:106:5
UpdateSessionStoreForStorage@resource://gre/modules/SessionStoreFunctions.jsm:49:35
sleep@resource://testing-common/mozmill/utils.jsm:62:12
triggerKeyEvent@resource://testing-common/mozmill/events.jsm:154:9
MozMillController.prototype.type/<@resource://testing-common/mozmill/controller.jsm:272:12
MozMillController.prototype.type@resource://testing-common/mozmill/controller.jsm:271:21
setup_msg_contents@resource://testing-common/mozmill/ComposeHelpers.jsm:349:8
testWarningShowsWhenCcFieldHitLimit@chrome://mochitests/content/browser/comm/mail/test/browser/composition/browser_publicRecipientsWarning.js:64:21
Tester_execTest/<@chrome://mochikit/content/browser-test.js:1089:34

This looks like another case of using processNextEvent here. The tests complete with OK but i think they are actually being ended abruptly.

Example from logs

https://treeherder.mozilla.org/logviewer?job_id=341401091&repo=comm-central&lineNumber=25079

SessionStoreFunctions.jsm does the unholy import of SessionStore.jsm which is not in toolkit/ but browser/
One of these hits must be a recent cpp import of that module... https://searchfox.org/mozilla-central/search?q=SessionStoreFunctions.jsm&path=

If I understand this correctly, can this be resolved by adding our own SessionStore.jsm and overwriting the import path?

Edit: Seems like that would work although other related modules would have to be imported as well.
Edit2: This seems like a lot of browser specific stuff to port over. Maybe I should just shim out SessionStore.
Do we rely on these session apis?

Adding a no-op shim for SeessionStore.jsm should be possible, even if not pretty.

Looks like the changes in bug 1700623 made these show up.

SessionStoreFunctions.jsm is a strange creature... It's basically just forwarding to the (browser only) SessionStore.jsm.

Andreas, do you see better solution then shimming here?

This actually came up in a meeting last week, and it is indeed a bit unfortunate that things in toolkit/components/sessionstore does stuff that's not so toolkit'y. We've been working fast instead of correct to get session store fission compatible. Real sorry about that, but I guess it's been inevitable.

So I wonder if the right solution isn't on the Gecko end of things, where we do the right thing with SessionStoreFunctions.jsm instead. But that might be a bit hard for us to prioritize currently, so if the shim solution would work for you that might be the quicker solution.

But that also depends on how you use Session Store. With a no-op shim for SessionStore.jsm you're not going to collect web page session data "automatically", but if you don't rely on that a no-op shim would be perfect, I guess.

This affects the tests I wrote for bug 119977 and previous mail pill tests so I'm providing a shim in the mean time.

Thanks! Thunderbird doesn't use the session store. Since we don't really have browsing, there's little need for it. We only store what tabs we have open before quitting, and restore them on startup. Simplistic, but there hasn't been many complaints about it. https://searchfox.org/comm-central/source/mail/base/modules/SessionStoreManager.jsm

Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/fe597e7727de
Implement minimal SessionStore.jsm to prevent SessionStoreFunctions errors. r=mkmelin