Repository navigation
[macOS 27] All WebView content renders blank: first-run Setup Wizard hangs forever (GuideFrame::ShowModal), Home/Login/Device pages empty #12575
Description
Type of issue
Crash / freeze (the app crashes, hangs, or stops responding)
Bambu Studio Version
02.08.04.61 - all versions
Where is the application from?
Bambu Lab GitHub releases
OS version
27.0.1
Additional system information
Environment
- Bambu Studio: 02.08.04.61 (also reproduced on stable 02.08.02.61)
- macOS: 27.0.1 (Build 26A434)
- Hardware: MacBook Air M5 (Apple Silicon, native, not Rosetta)
- Printer: A1 mini
Description
On macOS 27, every WebView-based part of Bambu Studio renders as a completely blank window. On a clean install, this makes the app unusable: the first-run Setup Wizard opens as an empty modal window that can't be interacted with or closed (Esc, Cmd+W and the close button do nothing), so the user never reaches the main window.
OrcaSlicer shows the same behavior on this machine, which suggests the root cause is the shared WebView (WKWebView) integration on macOS 27.
Steps to reproduce
- On macOS 27.0.1, delete
~/Library/Application Support/BambuStudio(orBambuStudioBeta) to simulate a fresh install. - Launch Bambu Studio.
- The Setup Wizard window appears completely blank and the app is stuck there.
Diagnostics
Console output stops at:
[trace] Initializing StaticPrintConfigs
The process is not frozen. sample shows the main thread idle, inside the wizard's modal loop:
GUI_App::post_init()
→ GUI_App::config_wizard_startup()
→ GUI_App::run_wizard(RunReason, StartPage)
→ GuideFrame::run(bool&)
→ DPIAware<wxDialog>::ShowModal()
→ wxModalEventLoop::OSXDoRun()
→ mach_msg2_trap (idle, waiting for events)
So the dialog is running, but its WebView content is never drawn.
Workaround (confirmed)
Skip the wizard by pre-populating the config, so only_default_printers() returns false:
CONF=~/Library/Application\ Support/BambuStudioBeta/BambuStudio.conf
plutil -replace presets.machine -string "Bambu Lab A1 mini 0.4 nozzle" "$CONF"
plutil -replace presets.process -string "0.20mm Standard @BBL A1M" "$CONF"
plutil -replace presets.filaments -json '["Bambu PLA Basic @BBL A1M"]' "$CONF"
plutil -replace models -json '[{"model":"Bambu Lab A1 mini","nozzle_diameter":"0.4","vendor":"BBL"}]' "$CONF"
After this, the main window and the 3D/Prepare/Preview views (OpenGL) work fine and slicing works. However, Home, Login, Device and MakerWorld are still blank, so cloud printing and login are not usable from the app.
Already tried (no effect)
- Fresh reinstall, including deleting the app data folder
- Launching with "Open using Rosetta"
- Clearing
~/Library/WebKit/com.bambulab.bambu-studio*and~/Library/Caches/com.bambulab.bambu-studio* - Checking for stale instances and Local Network permission
- Latest stable and beta releases
Expected behavior
WebView pages (Setup Wizard, Home, Login, Device) render normally on macOS 27, as they do on macOS 26.
Suggestions
- Fix WKWebView rendering on macOS 27. This looks related to the earlier WebView loading issue on macOS 26.5+ that was fixed in 2.7.1.62.
- Add a fallback: if the wizard's WebView fails to load, allow skipping it or selecting a printer through a native dialog, so new users aren't hard-blocked.
I can provide the full sample output or test builds on request.
Printer
A1 Mini
How to reproduce
- Use a Mac running macOS 27.0.1 (tested on MacBook Air M5, Apple Silicon).
- Install Bambu Studio (latest stable or beta) and quit it if it's running.
- Delete the app data folder to simulate a fresh install:
rm -rf ~/Library/Application\ Support/BambuStudioBeta
(or ~/Library/Application Support/BambuStudio for the stable build) - Launch Bambu Studio.
- Result: the first-run Setup Wizard opens as a completely blank window. It can't be used or closed, and the app never reaches the main window.
- (Optional) Apply the config workaround from the description to skip the wizard. The main window then opens, but Home, Login, Device and MakerWorld remain blank.
Reproducible 100% of the time on this machine. OrcaSlicer shows the same blank wizard.
Actual results
The Setup Wizard window opens but is completely blank (white/empty). Nothing is drawn inside it, and it can't be interacted with or closed (Esc, Cmd+W and the close button do nothing). The app stays stuck on this modal window indefinitely and never shows the main window.
The process is not frozen. A sample of the process shows the main thread idle inside GuideFrame::run → wxDialog::ShowModal (modal event loop waiting for events), so the dialog is running but its WebView content is never rendered. Full sample attached.
After skipping the wizard with a config workaround, the main window opens and the 3D/Prepare/Preview views work, but Home, Login, Device and MakerWorld (all WebView-based) are also completely blank.
Expected results
The Setup Wizard should render normally so the user can select region, printer and filaments and finish the first-run setup. After that, Home, Login, Device and MakerWorld should load and display their content, as they do on macOS 26.
File uploads (project / log / crash dump / performance profile)
Checklist of files to include
- Project file (always)
- Log file (always)
- Crash dump / report — required for crash / freeze issues (Windows .dmp / macOS .ips / Linux gdb backtrace)
- Performance profile — required for performance / lag issues
Activity
Florin4226 commentedon Oct 11, 2026
Update: root cause found + workaround.
The WebKit GPU process launches (GPUProcessProxy::didFinishLaunching), then hangs during CoreAudio init
(right after TCCAccessRequest() / HALPlugInManagement::RegisterPlugIns) and is killed after ~4s
("GPUProcess ... became unresponsive, terminating it"). WebContent processes then time out
(RemoteRenderingBackendProxy::connection() ... error: Timeout), so all WebView pages stay blank.
Workaround that fixed it for me (Home, Login, Device all work):
sudo killall coreaudiod
BID=$(defaults read /Applications/BambuStudio.app/Contents/Info CFBundleIdentifier)
for k in UseGPUProcessForMediaEnabled UseGPUProcessForDOMRenderingEnabled UseGPUProcessForCanvasRenderingEnabled UseGPUProcessForWebGLEnabled; do
defaults write "$BID" "WebKitDebug$k" -bool false; defaults write "$BID" "WebKit$k" -bool false
done
Suggested fix: avoid initializing audio/media in the WebKit GPU process for these WebViews
(e.g. disable GPU process for media in the WKWebView configuration), and/or add a fallback
when the GPU process becomes unresponsive.
BambulabRobot commentedon Oct 11, 2026
Hi, thank you for taking the time to report this issue and for the details you've already provided — they are very helpful!
To help us pinpoint the root cause more accurately, it would be great if you could also share:
Of course, if you have any other context (screenshots, screen recordings, software version, OS info, etc.),feel free to add them as well. We appreciate your help and patience!
Fonant commentedon Oct 12, 2026
Not sure if this works on MacOS, but I think it's Linux-based, and a similar fix might work.
The summary is "try clearing the font cache":
#12414 (comment)
latu-bambulab commentedon Oct 13, 2026
Thank you very much for your feedback and suggestions for fixes.
In your case, the WebKit GPU process is freezing upon startup due to an issue with the local audio component. Simply disabling audio/video functionality would render some of our features unavailable. Attempting to recover the GPU process upon detecting an anomaly would likely result in the process restarting and freezing again. As for falling back to native pages—given the large number of pages currently using WebView—redeveloping them all natively would be costly and impractical.
But, we are currently working on replacing WKWebView with CEF, so we ask for your patience.
abnmp13 commentedon Oct 13, 2026
Nothing works for me. Eagerly awaiting a fix.
Florin4226 commentedon Oct 13, 2026
Thanks a lot for the detailed explanation, that makes sense. Good to hear about the move to CEF.
Two small notes in case they help in the meantime:
The workaround I used doesn’t seem to turn off audio/video completely. As far as I understand, UseGPUProcessForMediaEnabled = false only moves media handling out of the GPU process into the web content process. After applying it, Home, Login, Device all work normally for me. You’d know better whether any of your features depend on media running in the GPU process specifically.
Since this is likely to affect other macOS 27 users, it would help to add the workaround to the wiki/FAQ, or to show a short message when the WebKit GPU process becomes unresponsive. Right now users just see a blank window with no hint about the cause.
abnmp13 commentedon Oct 15, 2026
Still a blank window for me.
fix(macos): recover when WebKit abandons its GPU process at launch (#…