Load via SOOverrideURL in GameUserSettings.ini. Bridge status: Checking...
Social (15 functions)
get-idle-state returns the current EUserIdleState (Active/Idle/Away). subscribe-idle-state-changes registers for outbound idle-state-changed pushes - observe via Long Poll. mic-permission-changed-subscribe registers for outbound mic-permission-changed pushes with payload {isAllowed:bool} (true iff OS mic permission is authorized) - polled at 1s, fires only on transition.
Voice-party tray state - new in v10 (DISTRO-13486)
Inbound push (overlay -> launcher, fire-and-forget) of the voice/party state that drives the Windows system-tray icon when the Launcher is backgrounded. Routes FEOSSocialNotificationHandler::HandleVoicePartyStateChanged -> ISocialSettingsProvider::SetVoicePartyState -> IVoicePartyStateService -> IWindowsSystemTray::SetIconState. Unknown states (e.g. "Bogus") are rejected with a Warning and the icon is left unchanged. Background the Launcher and watch the tray icon (and the launcher log under -eosverbose).
Sends a desktop toast. When user clicks it, notification-actioned is pushed back via Long Poll.
Both buttons share a fixed conversationId="conv-pending". Fire "Send Notify" several times - when toasts are suppressed (fullscreen game / DND / Focus Assist) they pile up in FNotificationService::NotificationQueue all under the same id. Then click "Conversation Read" to drop the whole batch via ClearNotificationsByConversationId. Live (already-showing) toasts are intentionally not faded.
Common (3 functions)
Opens the URL in the system default browser via ICommonProvider::LaunchExternalUrl. get-window-state returns the current ELauncherWindowState (Foreground/Background/Minimized). subscribe-window-state-changes registers for outbound window-state-changed pushes - observe via Long Poll.
Game (3 functions) - new in v7 (DISTRO-13251)
Routes FEOSGameNotificationHandler -> IGameFeatureProvider -> IGameInviteManager::AcceptGameInvite/RejectGameInvite. join-game and accept-game-invite are intentionally aliased to the same provider call (matches legacy USocialJSBridge::JoinGame in SocialJSBridge.cpp:791). Restores the FN party-invite Join Game flow in -launcherlabel=EOSSDK builds.
ProductInfo (1 function)
TTS (9 functions)
STT (12 functions)
Outbound Events (Launcher -> Overlay, appear in Long Poll)
These are pushed automatically by the Launcher. Start Long Poll to observe them.
- social/notification-actioned - fires when user clicks a desktop toast (trigger via Send Notify above)
- social/screen-reader-state-changed - fires every 1s when screen reader state changes
- social/idle-state-changed - fires when user idle state transitions (subscribe via SubscribeIdleStateChanges above)
- social/mic-permission-changed - fires when OS microphone permission flips, payload {isAllowed:bool} (subscribe via SubscribeMicPermissionChanges above)
- common/window-state-changed - fires when launcher window state transitions (subscribe via SubscribeWindowStateChanges above)
- tts/speech-start|complete|error|progress - fires during TTS playback (trigger via StartSpeak above)
- stt/dictation-result|error|started|ended - fires during STT dictation (trigger via StartDictation above)
The overlay sends badge count via update-badge-count intent. The SDK fires EOS_UI_OnBadgeCountUpdatedCallback to the Launcher, which routes through OnBadgeCountUpdated event to SocialJSBridge.
Legacy CEF bridge equivalents of the EOS-SDK voice-party push (v11, DISTRO-13486), for older store pages on window.ue.social.*. getvoicepartystate() returns the current state string; voicepartystatechanged(cb) fires cb(state) on each change. Windows + UseEOSSDKSocial only - returns "not-in-party" and never pushes otherwise. Drive transitions from the v10 voice-party buttons above (or the overlay) after subscribing.
Triggered by a plain JS window.open(url, target, features) where target starts with EOSNativeWindow. CEF's OnBeforePopup inside the EOS overlay process intercepts it (see EOSOverlayWebview.cpp::FOverlayWebview::OnBeforePopup), creates a native HWND, and fires EOS_UI_OnPopupWindowCreatedCallback. That callback flows to the launcher via EOSManagerEGL -> FriendsAndChatManager::OnPopupWindowCreated -> FExternalChatPresentationImpl::HandleEOSPopupWindowCreated_EOS, which wraps the HWND in a Slate SWindow. The suffix after EOSNativeWindow becomes the Id field (EOSNativeWindowChat -> Id="Chat" reuses the existing ChatWindow member; EOSNativeWindow with no suffix -> empty Id; any other suffix lands in EOSExtraPopupWindows_EOS). Watch the launcher log for LogExternalChatPresentation and LogFriendsAndChatManager: OnEOSSDKPopupWindowCreated.
CEF target-name reuse: per the HTML window.open spec, calling window.open(url, target, ...) with a target name that ALREADY belongs to an open window will navigate that existing window rather than open a new one - and OnBeforePopup never fires on the second call, so the launcher gets no event. The buttons below side-step this by either (a) using distinct target names per variant or (b) closing the previous popup via WindowRef.close() before reopening.
"Open unnamed popup" has empty Id from the SDK. The launcher normalizes empty Id to "Chat" at the point of entry (see HandleEOSPopupWindowCreated_EOS) so both EOSNativeWindow and EOSNativeWindowChat share one map key and one close-binding Id - avoids alias bugs where a stale empty-key entry could route an alive-ticker cleanup to the wrong wrapper. Opening this while Chat is already open replaces Chat (and vice versa). Expected.
These use distinct target names (EOSNativeWindowChat900x600, EOSNativeWindowChat500x350) so CEF can't reuse a previously-opened browser. The Id is the suffix after EOSNativeWindow, so these land in EOSExtraPopupWindows_EOS (not the ChatWindow slot). Exercises popupFeatures.widthSet/heightSet/xSet/ySet -> FEOSPopupWindowCreated::Width/Height/X/Y.
JS-side close is not possible in this setup. CEF returns null from window.open whenever OnBeforePopup swaps in a custom client (which it does for every EOSNativeWindow* target - see FOverlayWebview::OnBeforePopup: client = new FNativePopupWebview(...)). The calling JS never receives a Window handle, so WindowRef.close() can't be called. Close popups manually via the wrapper's title-bar X button - this destroys the Slate wrapper's native HWND, and Windows then cascades DestroyWindow to the cross-process EOS child HWND (the child was reparented under the wrapper at popup-create time and re-styled WS_CHILD, so it dies with its parent). CEF observes the HWND going away and releases the target name; the next window.open with the same target works as a fresh popup. (The narrow case where the wrapper is destroyed before the deferred reparent fires is handled separately by HandleEOSPopupWindowCreated_EOS's realize ticker, which PostMessages WM_CLOSE to the orphan EOS HWND.) This button just lists what's been opened from this page.
For comparison: opens with target="_blank". Does NOT trigger the native-popup path; CEF spawns a regular off-screen tab inside the overlay process. Use this if you suspect the EOS-prefixed buttons aren't reaching OnBeforePopup at all.