macOS 26.3 (M4) Dropbox v243.3.6895: CxSupportTool window loop + Chromium 102 renderer abort

Application Affected: Dropbox Desktop (macOS)
Device: MacBook Pro M4 Max, 36GB RAM
Operating System: macOS 26.3 Tahoe (Apple Silicon)
Dropbox App Version: 243.3.6895 (Electron 19.1.9-dropbox.50 / Chromium 102)
Subscription: Dropbox Pro

Question / Issue

Two distinct bugs prevent normal use of the Dropbox desktop client:

1. CxSupportTool diagnostic window launches automatically every 2-12 seconds whenever any Dropbox UI is opened (Settings, tray popup), displaying raw sync engine debug output to the end user. This makes the Settings UI unusable and predates macOS Tahoe.
2. Renderer processes abort on macOS 26 due to a FATAL:logging.cc failure in Chromium 102, causing IPC errors and renderer death. This is macOS 26-specific.

---

Bug 1: CxSupportTool Diagnostic Overlay

Reproduction Steps

1. Launch Dropbox normally
2. Click the Dropbox menu bar icon
3. Open Settings/Preferences (or interact with the tray UI)
4. Wait 2-12 seconds
5. A 960x540 window titled "CX Support Tool" appears, showing raw sync engine diagnostics:
   • PhaseInformation, SyncStatus, EngineWaitTracker, PendingSetTracker
   • Pending set count (600-900+ items), capped: true
6. Closing the window does not help - it reappears within seconds
7. The cycle repeats indefinitely, making Settings navigation impossible

Observed Behavior

The diagnostic window is not a crash dialog - the main process and renderer processes remain alive. The window is a fully rendered BrowserWindow (cxSupportToolView) spawned by the Dropbox "journey" system. It displays the output of fetchEngineDebugInfo(), which is internal sync engine state not meant for end users.

The issue persists across:

• Multiple macOS versions (predates Tahoe)
• Clean reinstalls of Dropbox
• Clearing all local caches and crash data

Root Cause Analysis

I extracted and analyzed app.asar and traced the trigger chain:

SyncErrorServiceImpl detects sync errors
  → fetchEngineDebugInfo() IPC call
  → CxSupportToolController.launchJourney() (module 898 in main.js)
  → spawnViewWithServices() creates BrowserWindow (960×540)
  → cxSupportToolView renders engine debug info

CxSupportToolController (in main.js module 898) extends BaseUserJourneyController and is registered as:

registerUserJourney(
  UserJourneyType.CX_SUPPORT_TOOL_FLOW,
  { singleton: true, controllerClass: CxSupportToolController }
)

The journey is launched by SyncErrorServiceImpl when the sync engine's pending set enters a "capped" state. Telemetry is tagged under DesktopComponent.SYNC_ERRORS.

Why the sync engine is capped: The user's Dropbox folder contains software development projects with node_modules, .git, and __pycache__ directories totaling approximately 965,000 files. These small, numerous files overwhelm the sync engine's pending set tracker, causing it to cap (a circuit-breaker mechanism). The capped state is then interpreted by SyncErrorServiceImpl as a sync error, which repeatedly launches the diagnostic journey.

Storing development projects in cloud-sync folders is common. The sync engine should handle large file counts without surfacing internal diagnostics to users.

Workaround Applied

1. Set com.dropbox.ignored extended attribute on node_modules (17 dirs), .git (44 dirs), and __pycache__ (86 dirs) to exclude them from sync
2. Patched app.asar to replace CxSupportToolController.launchJourney method body with return{result:0} (same byte length to preserve asar offsets), preventing the diagnostic window from spawning

The asar patch is temporary - the auto-updater will overwrite it.

Suggested Fixes

1. Do not show raw engine debug info to end users. The CxSupportToolView displays PhaseInformation, SyncStatus, EngineWaitTracker, and PendingSetTracker output - this is engineering diagnostic data with no actionable information for customers.
2. Add rate limiting or debounce to CxSupportToolController.launchJourney(). Currently, when SyncErrorServiceImpl detects a capped pending set, it can launch the journey repeatedly (every 2-12 seconds). Even if the diagnostic window is appropriate in some contexts, it should not spawn in an unbounded loop.
3. Don't treat a capped pending set as a user-facing sync error. A large number of pending files is a normal condition for users with many small files (developers, photographers, etc.). The sync engine's circuit breaker should not trigger a customer-facing diagnostic journey - it should log internally and continue processing.
4. Auto-ignore common regenerable directories. Directories like node_modules, .git, __pycache__, venv, and build are well-known to be regenerable and contain large numbers of small files. These could be suggested for exclusion or ignored by default when detected, similar to how .gitignore patterns work.

---

Bug 2: Chromium 102 Renderer FATAL Abort on macOS 26

Reproduction Steps

1. Run Dropbox on macOS 26.3 Tahoe
2. Observe stderr output (launch with ELECTRON_ENABLE_LOGGING=1)
3. Renderer processes emit: FATAL:logging.cc(144) Failed to init logging: Operation not permitted
4. Renderers abort immediately
5. Main process logs: Error: Render frame was disposed before WebFrameMain could be accessed

Root Cause

Chromium 102 (used by Electron 19.1.9-dropbox.50) attempts to initialize file-based logging inside the renderer sandbox. macOS 26 tightened sandbox permissions, causing the logging.cc initialization fails with 'Operation not permitted'. Chromium treats this as a FATAL error, which calls abort() and kills the renderer process.

The Electron project tracks similar issues with older Chromium on newer macOS (e.g., electron/electron#48311).

Workaround

Setting CHROME_LOG_FILE=/dev/null before launching Dropbox prevents the FATAL abort:

CHROME_LOG_FILE=/dev/null /Applications/Dropbox.app/Contents/MacOS/Dropbox

This sidesteps the permission failure by redirecting Chromium's log file.

Suggested Fix

Upgrade the Electron/Chromium runtime. Electron 19 (Chromium 102) is from June 2022 and EOL. Newer Chromium handles macOS sandbox changes fine. At the very least, logging.cc init should handle permission failures instead of calling abort().

---

Environment Details

Diagnostic Artifacts

I collected the following during the investigation and can provide any of it on request:

• Stderr logs from multiple launch configurations (ELECTRON_ENABLE_LOGGING=1, CHROME_LOG_FILE=/dev/null)
• Extracted and annotated sections of main.js (module 898 - CxSupportToolController)
• Extracted cxSupportToolView renderer and preload scripts
• apex.sqlite3 Stormcrow configuration (feature flag state)
• Screenshots of the CxSupportTool diagnostic window
• Process traces showing the renderer FATAL abort sequence

Approaches That Did Not Resolve the Issue

Feel free to get in touch for any additional details or inquiries.

Best regards,
Ryan

[personal information removed per the Community's Guidelines]