You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Split out of #719, which fixed the same underlying problem for X. Filing rather than fixing, because the right answer for Facebook is probably deletion, not a port.
The underlying finding
Chromium stopped exposing the Cookie request header to webRequest listeners. BaseAccountController registers ses.webRequest.onSendHeaders(...), and handleCookieTracking reads details.requestHeaders["Cookie"] out of it, so that map no longer fills.
Verified with the same listener on both runtimes:
Electron
Chromium
requestHeaders["Cookie"]
41.10.7
146
ct0=PROBEVALUE
44.4.3
152
null
For X this broke login outright: getCookie returned null, graphqlGetViewerUser logged ct0 is null, and the account was left with no username.
Why Facebook is different
Nothing reads Facebook's cookies. FacebookAccountController declares a cookies field and writes to it in handleCookieTracking, but there is no getCookie method, no IPC handler, and no preload binding — getCookie is exposed only as X:getCookie. The map has been write-only since it was added.
So there is no user-visible breakage to fix. What is there is dead code that also stopped working, plus a trap: anyone who later adds a Facebook cookie reader against this map gets silent nulls, which is a slow thing to debug.
Options
Delete it. Remove the cookies field and the handleCookieTracking override. The base class already has a no-op default (added in Upgrade dependencies: 79 advisories down to 24, no criticals #719), so nothing else has to change. If that leaves X and Facebook both opted out, the onSendHeaders registration in BaseAccountController can go too.
Give Facebook a working getCookie on the model X now uses — session.cookies.get({ url, name }) — but only if there is a near-term need for it. X needs cookies for GraphQL deletes; it is not clear Facebook has an equivalent.
Option 1 unless someone knows of planned work that needs Facebook cookies.
Pointers
X fix: commit 609b78a1 on deps-upgrade-2026-09, plus src/account_x/__tests__/unit/controller.cookies.unit.test.ts for the shape of a test that does not presuppose the header.
The mock in src/__tests__/platform-fixtures/electronMocks.ts supplies a Cookie header to onSendHeaders, so the suite cannot currently catch this class of failure. It now also has a seedable cookie jar.
Facebook code: src/account_facebook/facebook_account_controller.ts, the cookies field and handleCookieTracking.
Split out of #719, which fixed the same underlying problem for X. Filing rather than fixing, because the right answer for Facebook is probably deletion, not a port.
The underlying finding
Chromium stopped exposing the
Cookierequest header towebRequestlisteners.BaseAccountControllerregistersses.webRequest.onSendHeaders(...), andhandleCookieTrackingreadsdetails.requestHeaders["Cookie"]out of it, so that map no longer fills.Verified with the same listener on both runtimes:
requestHeaders["Cookie"]ct0=PROBEVALUEnullFor X this broke login outright:
getCookiereturned null,graphqlGetViewerUserloggedct0 is null, and the account was left with no username.Why Facebook is different
Nothing reads Facebook's cookies.
FacebookAccountControllerdeclares acookiesfield and writes to it inhandleCookieTracking, but there is nogetCookiemethod, no IPC handler, and no preload binding —getCookieis exposed only asX:getCookie. The map has been write-only since it was added.So there is no user-visible breakage to fix. What is there is dead code that also stopped working, plus a trap: anyone who later adds a Facebook cookie reader against this map gets silent nulls, which is a slow thing to debug.
Options
cookiesfield and thehandleCookieTrackingoverride. The base class already has a no-op default (added in Upgrade dependencies: 79 advisories down to 24, no criticals #719), so nothing else has to change. If that leaves X and Facebook both opted out, theonSendHeadersregistration inBaseAccountControllercan go too.getCookieon the model X now uses —session.cookies.get({ url, name })— but only if there is a near-term need for it. X needs cookies for GraphQL deletes; it is not clear Facebook has an equivalent.Option 1 unless someone knows of planned work that needs Facebook cookies.
Pointers
609b78a1ondeps-upgrade-2026-09, plussrc/account_x/__tests__/unit/controller.cookies.unit.test.tsfor the shape of a test that does not presuppose the header.src/__tests__/platform-fixtures/electronMocks.tssupplies aCookieheader toonSendHeaders, so the suite cannot currently catch this class of failure. It now also has a seedable cookie jar.src/account_facebook/facebook_account_controller.ts, thecookiesfield andhandleCookieTracking.(This was written by an LLM.)