Open Bug 1971889 Opened 9 months ago Updated 7 months ago

SessionStore doesn't seem to initialize properly on first launch when MOZ_DATA_REPORTING is false/not defined

Categories

(Firefox :: Session Restore, defect)

Product:
Firefox
Component:
Session Restore
Version:
Firefox 128
Type:
defect

Tracking

()

Status:
UNCONFIRMED

People

(Reporter: k4sum1, Unassigned)

Details

Steps to reproduce:

This is a really hard issue to get to occur, not one specific thing causes it, it seems to be a combination of things. I'd assume it still occurs in the latest build, but the easiest way I know to get it to occur is to build a version that is affected by https://bugzilla.mozilla.org/show_bug.cgi?id=1908019 like 128 ESR. However that also means I'm constrained by the bug in testing, so I'm not sure how to trace it to a version before the bug occurred yet.

First needed is a mozconfig with a bunch of privacy(?) settings. I'm not sure what specifically is needed yet, I'm working on narrowing it down. This is the one I've tested and confirmed it to occur with.
https://github.com/Eclipse-Community/r3dfox/blob/05728657f0f6ec04e655dd8c68c3ad803fcba816/mozconfigs/mozconfig-win-x64-utest

Next, in browser/moz.configure both MOZ_SERVICES_HEALTHREPORT and MOZ_NORMANDY need to be set to False. In my testing, just one or the other doesn't seem to make it occur and I have no idea why.

Actual results:

I will be using the issue https://bugzilla.mozilla.org/show_bug.cgi?id=1908019 as an example here. See above for an explanation for why.

Open the browser
Ctrl + B to open bookmarks sidebar
Close the browser
Open the browser again
Bookmarks sidebar missing

Expected results:

In this chain of events the bookmarks sidebar should be open on the next launch since it was open before. However it's not.

I have found that if you flip History to Use custom settings for history (maybe restart browser here too), then flip it back to Remember history, the bookmarks sidebar still stays open upon browser restarts, which means this somehow fixes the issue with SessionStore here. I'm not completely sure how or why, but a quick and dirty fix could be to flip the history setting back and forth on first launch.

The Bugbug bot thinks this bug should belong to the 'Firefox::Session Restore' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Session Restore

Hello I have tried to reproduce the issue with firefox 141.0a1(2025-06-16) on Windows 10 and Ubuntu 22.04 unfortunately I wasn't able to do so.
Could you please answer the following questions in order to further investigate this issue?

  1. Does this issue happen with a new profile? Here is a link on how to create one: https://support.mozilla.org/en-US/kb/profile-manager-create-remove-switch-firefox-profiles
  2. Could you please provide a screen recording with the issue?
Flags: needinfo?(k4sum1)

(In reply to Negritas Sergiu, Desktop QA from comment #2)

Hello I have tried to reproduce the issue with firefox 141.0a1(2025-06-16) on Windows 10 and Ubuntu 22.04 unfortunately I wasn't able to do so.
Could you please answer the following questions in order to further investigate this issue?

  1. Does this issue happen with a new profile? Here is a link on how to create one: https://support.mozilla.org/en-US/kb/profile-manager-create-remove-switch-firefox-profiles
  2. Could you please provide a screen recording with the issue?

I don't know of a way to reproduce the exact issue on latest. The only symptom that I can 100% confirm is caused by this was fixed in a somewhat bandaid manner in later releases. Which means the core issue could still happen, but I don't know of a way to get it to show.

I do know you can reproduce it on latest ESR 128, but you have to build it yourself with the configurations I sent above. It's not something that (afaik) you would see in any official Mozilla release.

I tested with a new profile every time.

Here is a video of the bug

https://files.catbox.moe/auwvh1.mp4

I have found that if you flip History to Use custom settings for history (maybe restart browser here too), then flip it back to Remember history, the bookmarks sidebar still stays open upon browser restarts, which means this somehow fixes the issue with SessionStore here. I'm not completely sure how or why, but a quick and dirty fix could be to flip the history setting back and forth on first launch.

https://files.catbox.moe/9gz7cg.mp4

I'm going to try to further reduce the configurations in the mozconfig and go down to what is only required to cause this.

Flags: needinfo?(k4sum1)

Ok, so I think all the mozconfig needs is ac_add_options --disable-crashreporter to cause the issue, along with MOZ_SERVICES_HEALTHREPORT and MOZ_NORMANDY set to false

I also have these set just to make building faster. I doubt they affect the issue here.

ac_add_options --disable-debug-js-modules
ac_add_options --disable-debug-symbols
ac_add_options --disable-tests

In console with --disable-crashreporter I get this

$ MOZCONFIG=C:/Users/Admin/Documents/GitHub/r3dfox/mozconfigs/mozconfig-win-x64-utest ./mach run
 0:00.77 'C:/Users/Admin/Documents/GitHub/r3dfox/obj-x86_64-pc-windows-msvc\dist\bin\firefox.exe' -no-remote -wait-for-browser -profile 'C:\Users\Admin\Documents\GitHub\r3dfox\obj-x86_64-pc-windows-msvc\tmp\profile-default'
-attach-console
console.error: "getScreenshot(https://apnews.com/) failed:" (new Error("page-thumbnail:error", "resource://gre/modules/BackgroundPageThumbs.sys.mjs", 141))
console.error: "getScreenshot(https://apnews.com/) failed:" (new Error("page-thumbnail:error", "resource://gre/modules/BackgroundPageThumbs.sys.mjs", 141))
console.error: "getScreenshot(https://apnews.com/) failed:" (new Error("page-thumbnail:error", "resource://gre/modules/BackgroundPageThumbs.sys.mjs", 141))
console.error: "Failed to fetch https://firefox-api-proxy.cdn.mozilla.net/desktop/v1/recommendations?locale=en-US&region=US&count=30:" "NetworkError when attempting to fetch resource."
console.error: "No response for feed"
console.error: "Failed to fetch https://firefox-api-proxy.cdn.mozilla.net/desktop/v1/recommendations?locale=en-US&region=US&count=30:" "NetworkError when attempting to fetch resource."
console.error: "No response for feed"
console.error: (new TypeError("NetworkError: Network request failed", "resource://services-settings/Utils.sys.mjs", 236))
JavaScript error: resource:///actors/AboutNewTabParent.sys.mjs, line 48: InvalidStateError: An attempt was made to use an object that is not, or is no longer, usable

If I remove --disable-crashreporter, the bug is gone, but it hangs at exit and I get this.

$ MOZCONFIG=C:/Users/Admin/Documents/GitHub/r3dfox/mozconfigs/mozconfig-win-x64-utest ./mach run
 0:00.88 'C:/Users/Admin/Documents/GitHub/r3dfox/obj-x86_64-pc-windows-msvc\dist\bin\firefox.exe' -no-remote -wait-for-browser -profile 'C:\Users\Admin\Documents\GitHub\r3dfox\obj-x86_64-pc-windows-msvc\tmp\profile-default'
-attach-console
console.error: ({})
console.error: "getScreenshot(https://apnews.com/) failed:" (new Error("page-thumbnail:error", "resource://gre/modules/BackgroundPageThumbs.sys.mjs", 141))
console.error: "getScreenshot(https://apnews.com/) failed:" (new Error("page-thumbnail:error", "resource://gre/modules/BackgroundPageThumbs.sys.mjs", 141))
console.error: "getScreenshot(https://apnews.com/) failed:" (new Error("page-thumbnail:error", "resource://gre/modules/BackgroundPageThumbs.sys.mjs", 141))
console.error: "getScreenshot(https://apnews.com/) failed:" (new Error("page-thumbnail:error", "resource://gre/modules/BackgroundPageThumbs.sys.mjs", 141))
console.error: "getScreenshot(https://apnews.com/) failed:" (new Error("page-thumbnail:error", "resource://gre/modules/BackgroundPageThumbs.sys.mjs", 141))
WARNING: At least one completion condition is taking too long to complete. Conditions: [{"name":"JSON store: writing data for 'targeting.snapshot'","state":{"sanitizedBasename":"targeting.snapshot"},"filename":"resource://gr
e/modules/JSONFile.sys.mjs","lineNumber":126,"stack":["resource://gre/modules/JSONFile.sys.mjs:JSONFile:126","resource://gre/modules/BackgroundUpdate.sys.mjs:scheduleFirefoxMessagingSystemTargetingSnapshotting:766","resource
:///modules/BrowserGlue.sys.mjs:task:3097","resource:///modules/BrowserGlue.sys.mjs:_scheduleStartupIdleTasks/<:3240"]}] Barrier: IOUtils: waiting for profileBeforeChange IO to complete
WARNING: At least one completion condition is taking too long to complete. Conditions: [{"name":"IOUtils Blocker (profile-before-change)","state":"(none)","filename":"C:/Users/Admin/Documents/GitHub/r3dfox/dom/system/IOUtils
.cpp","lineNumber":2375,"stack":"IOUtils::EventQueue::SetShutdownHooks"}] Barrier: profile-before-change
*** UTM:SVC TimerManager:registerTimer called after profile-before-change notification. Ignoring timer registration for id: telemetry_modules_ping
*** UTM:SVC TimerManager:registerTimer called after profile-before-change notification. Ignoring timer registration for id: telemetry_untrustedmodules_ping
FATAL ERROR: AsyncShutdown timeout in IOUtils: waiting for profileBeforeChange IO to complete Conditions: [{"name":"JSON store: writing data for 'targeting.snapshot'","state":{"sanitizedBasename":"targeting.snapshot"},"filen
ame":"resource://gre/modules/JSONFile.sys.mjs","lineNumber":126,"stack":["resource://gre/modules/JSONFile.sys.mjs:JSONFile:126","resource://gre/modules/BackgroundUpdate.sys.mjs:scheduleFirefoxMessagingSystemTargetingSnapshot
ting:766","resource:///modules/BrowserGlue.sys.mjs:task:3097","resource:///modules/BrowserGlue.sys.mjs:_scheduleStartupIdleTasks/<:3240"]}] At least one completion condition failed to complete within a reasonable amount of t
ime. Causing a crash to ensure that we do not leave the user with an unresponsive process draining resources.
WARNING: No crash reporter available
[Parent 7628, Main Thread] ###!!! ABORT: file resource://gre/modules/JSONFile.sys.mjs:126

If I set MOZ_SERVICES_HEALTHREPORT and MOZ_NORMANDY back to true, the browser exits fine like this.

Admin@FurryFoxVM-Micro ~/Documents/GitHub/r3dfox
$ MOZCONFIG=C:/Users/Admin/Documents/GitHub/r3dfox/mozconfigs/mozconfig-win-x64-utest ./mach run
 0:00.84 'C:/Users/Admin/Documents/GitHub/r3dfox/obj-x86_64-pc-windows-msvc\dist\bin\firefox.exe' -no-remote -wait-for-browser -profile 'C:\Users\Admin\Documents\GitHub\r3dfox\obj-x86_64-pc-windows-msvc\tmp\profile-default'
-attach-console
console.error: ({})
console.error: "getScreenshot(https://apnews.com/) failed:" (new Error("page-thumbnail:error", "resource://gre/modules/BackgroundPageThumbs.sys.mjs", 141))
console.error: "getScreenshot(https://apnews.com/) failed:" (new Error("page-thumbnail:error", "resource://gre/modules/BackgroundPageThumbs.sys.mjs", 141))
console.error: "getScreenshot(https://apnews.com/) failed:" (new Error("page-thumbnail:error", "resource://gre/modules/BackgroundPageThumbs.sys.mjs", 141))
console.error: "getScreenshot(https://apnews.com/) failed:" (new Error("page-thumbnail:error", "resource://gre/modules/BackgroundPageThumbs.sys.mjs", 141))
console.error: "getScreenshot(https://apnews.com/) failed:" (new Error("page-thumbnail:error", "resource://gre/modules/BackgroundPageThumbs.sys.mjs", 141))
console.error: URLBar - QuickSuggest.SuggestBackendRust: "Ingest error: Java error: \"Request error: NS_ERROR_NET_RESET\""

I'm going to look into seeing if I can fix those warning/errors above and see if the issue persists.

Adding ac_add_options --disable-update-agent and ac_add_options --disable-updater removes all those errors, but it like actually just gets rid of all the leads.

Admin@FurryFoxVM-Micro ~/Documents/GitHub/r3dfox
$ MOZCONFIG=C:/Users/Admin/Documents/GitHub/r3dfox/mozconfigs/mozconfig-win-x64-utest ./mach run
 0:00.89 'C:/Users/Admin/Documents/GitHub/r3dfox/obj-x86_64-pc-windows-msvc\dist\bin\firefox.exe' -no-remote -wait-for-browser -profile 'C:\Users\Admin\Documents\GitHub\r3dfox\obj-x86_64-pc-windows-msvc\tmp\profile-default'
-attach-console
console.error: "getScreenshot(https://apnews.com/) failed:" (new Error("page-thumbnail:error", "resource://gre/modules/BackgroundPageThumbs.sys.mjs", 141))
console.error: "getScreenshot(https://apnews.com/) failed:" (new Error("page-thumbnail:error", "resource://gre/modules/BackgroundPageThumbs.sys.mjs", 141))
console.error: "getScreenshot(https://apnews.com/) failed:" (new Error("page-thumbnail:error", "resource://gre/modules/BackgroundPageThumbs.sys.mjs", 141))
console.error: "getScreenshot(https://apnews.com/) failed:" (new Error("page-thumbnail:error", "resource://gre/modules/BackgroundPageThumbs.sys.mjs", 141))
console.error: "getScreenshot(https://apnews.com/) failed:" (new Error("page-thumbnail:error", "resource://gre/modules/BackgroundPageThumbs.sys.mjs", 141))

Admin@FurryFoxVM-Micro ~/Documents/GitHub/r3dfox
$ MOZCONFIG=C:/Users/Admin/Documents/GitHub/r3dfox/mozconfigs/mozconfig-win-x64-utest ./mach run
 0:00.78 'C:/Users/Admin/Documents/GitHub/r3dfox/obj-x86_64-pc-windows-msvc\dist\bin\firefox.exe' -no-remote -wait-for-browser -profile 'C:\Users\Admin\Documents\GitHub\r3dfox\obj-x86_64-pc-windows-msvc\tmp\profile-default'
-attach-console
console.error: "Failed to fetch https://firefox-api-proxy.cdn.mozilla.net/desktop/v1/recommendations?locale=en-US&region=US&count=30:" "NetworkError when attempting to fetch resource."
console.error: "No response for feed"
console.error: "Failed to fetch https://firefox-api-proxy.cdn.mozilla.net/desktop/v1/recommendations?locale=en-US&region=US&count=30:" "NetworkError when attempting to fetch resource."
console.error: "No response for feed"

If I disable crashreporter again, I still have the issue, but I do get one new error, but I'm not sure how to diagnose it.

$ MOZCONFIG=C:/Users/Admin/Documents/GitHub/r3dfox/mozconfigs/mozconfig-win-x64-utest ./mach run
 0:00.81 'C:/Users/Admin/Documents/GitHub/r3dfox/obj-x86_64-pc-windows-msvc\dist\bin\firefox.exe' -no-remote -wait-for-browser -profile 'C:\Users\Admin\Documents\GitHub\r3dfox\obj-x86_64-pc-windows-msvc\tmp\profile-default'
-attach-console
console.error: "Failed to fetch https://firefox-api-proxy.cdn.mozilla.net/desktop/v1/recommendations?locale=en-US&region=US&count=30:" "NetworkError when attempting to fetch resource."
console.error: "No response for feed"
console.error: (new TypeError("NetworkError: Network request failed", "resource://services-settings/Utils.sys.mjs", 236))
console.error: "Failed to fetch https://firefox-api-proxy.cdn.mozilla.net/desktop/v1/recommendations?locale=en-US&region=US&count=30:" "NetworkError when attempting to fetch resource."
console.error: "No response for feed"

My guess is this Utils thing causes it, but I can't see why or how to diagnose it.

Ok so Utils error appears to be unrelated, I can have the issue occur with no errors or anything in the console.

However opening any(?) about page once seems to fix the issue, even something as basic as about:about and even about:blank

So the default Firefox behavior of opening about:welcome on start "fixes" the issue, and I can confirm that by setting pref("startup.homepage_welcome_url", "about:welcome"); and the browser doesn't have the issue.

What doesn't make sense is that about:home is well an about page, and this is what opens at launch without a welcome url set. Even manually going to about:home in the URL bar doesn't fix it either. Why does about:home not fix it when literally even about:blank does?

So I wonder if this issue is something old that got missed or worked around in multiple ways and it only shows after doing all of this. MOZ_SERVICES_HEALTHREPORT, MOZ_NORMANDY, crash reporter, and every other about page must have something in common that "fixes" the issue. I assume it's something SessionStore related not initializing properly until one of these conditions are met.

So I did some looking and found MOZ_DATA_REPORTING

# If we have any service that uploads data (and requires data submission
# policy alert), set MOZ_DATA_REPORTING.
# ==============================================================
@depends(
    "MOZ_TELEMETRY_REPORTING",
    "MOZ_SERVICES_HEALTHREPORT",
    "--enable-crashreporter",
    "MOZ_NORMANDY",
)
def data_reporting(telemetry, healthreport, crashreporter, normandy):
    return telemetry or healthreport or crashreporter or normandy


set_config("MOZ_DATA_REPORTING", True, when=data_reporting)
set_define("MOZ_DATA_REPORTING", True, when=data_reporting)

MOZ_TELEMETRY_REPORTING afaik seems to default to false if not defined. I see no reason for it to be defined on my machine, so it's false. MOZ_SERVICES_HEALTHREPORT and MOZ_NORMANDY are set to false in moz.configure, and --disable-crashreporter is set in the mozconfig, so MOZ_DATA_REPORTING doesn't get set, and whatever MOZ_DATA_REPORTING does "fixes" the issue.

So I added imply_option("MOZ_TELEMETRY_REPORTING", True) to moz.configure and that appears to also fix it. So yeah this looks to be it.

Later I will try removing the bits that depend on MOZ_DATA_REPORTING and see what specifically makes it work here.

Summary: Default SessionStore settings are somehow broken with multiple privacy configurations set when compiling → Default SessionStore settings are somehow broken when MOZ_DATA_REPORTING is false/not defined
Summary: Default SessionStore settings are somehow broken when MOZ_DATA_REPORTING is false/not defined → SessionStore is kinda broken when MOZ_DATA_REPORTING is false/not defined

So I have been quite busy, but I did confirm that is is specifically MOZ_DATA_REPORTING, and removing the above bit for it in toolkit/moz.configure makes the issue occur even when one of the four items above are defined.

I'll start removing the defines that depend on it and see what specifically "fixes" it.

Summary: SessionStore is kinda broken when MOZ_DATA_REPORTING is false/not defined → SessionStore doesn't seem to initialize properly on first launch MOZ_DATA_REPORTING is false/not defined
Summary: SessionStore doesn't seem to initialize properly on first launch MOZ_DATA_REPORTING is false/not defined → SessionStore doesn't seem to initialize properly on first launch when MOZ_DATA_REPORTING is false/not defined

I've been super busy, so I haven't been looking at this, but the fix that MOZ_DATA_REPORTING does is, pref("datareporting.policy.firstRunURL", "https://www.mozilla.org/privacy/firefox/");

Yes running that at startup or just going to that URL directly initializes SessionStore normally. At least it gives me somewhat of an idea of how to trace it, but I'm probably not going to feel up for it for a while. For now I think I'll just have my fork open about:preferences on new installs.

I now remember the version needs to be affected by https://bugzilla.mozilla.org/show_bug.cgi?id=1908019 so I can't trace it.

However it at least gives me an idea of how to get it to occur in a stock build.

Expected results:
In this chain of events the bookmarks sidebar should be open on the next launch since it was open before. However it's not.

I just want to check this isn't bug 1922777?
My other suggestion would be to set browser.sessionstore.loglevel to Debug and see if there's anything illuminating in the log files in sessionstore-logs directory in your profile

Thanks for digging into this one. It's clever to use the bookmarks sidebar state as a proxy for whether the SessionStore started up correctly, but I'm not sure that I can infer what's going on in SessionStore based on the application logs you posted.

Please attach any recent session restore logs from your profile directory, which - if they exist - should be in a sessionstore-logs directory in your profile directory (the location is linked in the about:support page)

To get more verbose logging, set browser.sessionstore.log.appender.file.logOnSuccess to true in about:config, and browser.sessionstore.loglevel to Debug (this is the default in Nightly)

If the crash reporting in your application logs are anything to go by, it looks like there could be a deadlock during startup. It seems like resource://gre/modules/BackgroundUpdate.sys.mjs:scheduleFirefoxMessagingSystemTargetingSnapshotting is trying to write a JSON file on startup but the profile directory is not ready for writing. At first glance, the BrowserGlue code on startup looks like it should be robust in the face of failures from the messaging system, but perhaps it is crashing before the SessionStore is able to start.

For your reference, here are the official developer docs for these data reporting preferences https://firefox-source-docs.mozilla.org/toolkit/components/telemetry/internals/preferences.html Note that MOZ_SERVICES_HEALTHREPORT and MOZ_NORMANDY seem to be deprecated in more recent versions of Firefox.

(In reply to Sam Foster [:sfoster] (he/him) from comment #11)

I just want to check this isn't bug 1922777?

No, the sidebar state here is not saved at all until I "fix" the SessionStore.

My other suggestion would be to set browser.sessionstore.loglevel to Debug and see if there's anything illuminating in the log files in sessionstore-logs directory in your profile

(In reply to Stephen Thompson [:sthompson] from comment #12)

To get more verbose logging, set browser.sessionstore.log.appender.file.logOnSuccess to true in about:config, and browser.sessionstore.loglevel to Debug (this is the default in Nightly)

I ensured this was the default and then opened the browser, opened the bookmarks sidebar, waited a bit, closed, and this is what I got.

First launch:

1750988923270	SessionStore	DEBUG	Can't read session file which doesn't exist: clean
1750988923281	SessionStore	DEBUG	Can't read session file which doesn't exist: recovery
1750988923299	SessionStore	DEBUG	Can't read session file which doesn't exist: recoveryBackup
1750988923300	SessionStore	DEBUG	Can't read session file which doesn't exist: cleanBackup
1750988923308	SessionStore	DEBUG	Can't read session file which doesn't exist: clean
1750988923441	SessionStore	DEBUG	Can't read session file which doesn't exist: recovery
1750988923458	SessionStore	DEBUG	Can't read session file which doesn't exist: recoveryBackup
1750988923518	SessionStore	DEBUG	Can't read session file which doesn't exist: cleanBackup
1750988923518	SessionStore	WARN	No readable session files found to restore, starting with empty session
1750988923518	SessionStore	DEBUG	Completed SessionFile.read() with result.origin: empty
1750988923518	SessionStore	DEBUG	No valid session found
1750988923949	SessionStore	DEBUG	initSession willRestore: false, SessionStartup.sessionType: 0

Closing: (This is the same in every other file, so I won't repeat it)

1750988924511	SessionStore.LogManager	DEBUG	Flushing file log

Second launch: (Launched, saw bookmarks sidebar state not restored, and closed)
Same as first launch.

Third Launch: (I reopened the browser, opened the bookmarks sidebar, went to about:preferences, and then closed the browser.)
Same as first launch.

Fourth launch: (I reopened the browser and saw the bookmarks sidebar opened)
Three new lines

1750989022471	SessionStore	DEBUG	Successful file read of clean file
1750989022471	SessionStore	DEBUG	Completed SessionFile.read() with result.origin: clean
1750989022471	SessionStore	DEBUG	isAutomaticRestoreEnabled: false
1750989022471	SessionStore	DEBUG	Discarding previous session as we have initialState
1750989022472	SessionStore	DEBUG	Previous shutdown ok? false, reason: N/A
1750989022788	SessionStore	DEBUG	initSession willRestore: false, SessionStartup.sessionType: 3
1750989022788	SessionStore	DEBUG	initSession deferred restore with 1 initial windows, 1 remaining windows
**1750989022790	SessionStore	DEBUG	restoreWindows will restore 1 windows**
**1750989022792	SessionStore	DEBUG	restoreWindow, will restore 0 tabs, restoreTabsLazily: true**
1750989022792	SessionStore	DEBUG	sessionstore-windows-restored
**1750989022806	SessionStore	DEBUG	All 1 windows restored**
1750989023184	SessionStore	DEBUG	initialState contains 0 pinned tabs

Going to about:preferences seems to have made restoreWindows work, which I guess could be what the sidebar relies on.

I then did a fifth launch to close the bookmarks sidebar, and a sixth to check if anything changed in the log, but nothing changed and it still restores All 1 windows.

If the crash reporting in your application logs are anything to go by, it looks like there could be a deadlock during startup. It seems like resource://gre/modules/BackgroundUpdate.sys.mjs:scheduleFirefoxMessagingSystemTargetingSnapshotting is trying to write a JSON file on startup but the profile directory is not ready for writing. At first glance, the BrowserGlue code on startup looks like it should be robust in the face of failures from the messaging system, but perhaps it is crashing before the SessionStore is able to start.

I think I was testing this on a 133 nightly which could've had this broken in some manner, I also don't have any update server so I assume it could just be freaking out because no update server. I disabled the updater since it's outside the scope of this and to reduce complexity, but let me know if I should retest having the updater enabled on the 128 branch I'm testing on now.

The severity field is not set for this bug.
:jswinarton, could you have a look please?

For more information, please visit BugBot documentation.

Flags: needinfo?(jswinarton)
Severity: -- → S4
Flags: needinfo?(jswinarton)
You need to log in before you can comment on or make changes to this bug.