The wizard's loading page waits for HandleStudio to be called with
userguide_profile_load_finish and jumps to its target page on it; if the
call never arrives, a fallback timer in the page jumps after 180 s.
GuideFrame started the profile load from the first wxEVT_WEBVIEW_NAVIGATED
event and ran HandleStudio in the page as soon as the data was ready. That
event is the navigation's commit, before the page's scripts have run, and
with the wizard's derived cache the data is ready about 100 ms later.
Since the web view is created with an empty URL so the translated strings
can be injected before the first load, the first navigated event is the
commit of about:blank, so the data is ready before the real page has even
begun loading and the call reaches a page without HandleStudio. WebKit
drops the error and nothing retries, so on macOS the wizard often sits on
"Loading..." for three minutes before the printer list appears.
The loading page now reports in from its OnInit, the way the other wizard
pages request what they need, and the host sends the message once both
the data is ready and the page has reported; every instance of the page
reports again, so one that replaced an earlier one gets its own message.
When running under XWayland (Wayland sessions with GDK_BACKEND=x11),
WebKit2GTK's compositing mode can fail silently, causing the Setup
Wizard WebView to freeze or render blank. This leaves users stuck on
the "Loading......" screen indefinitely.
Changes:
- Set WEBKIT_DISABLE_COMPOSITING_MODE=1 to force software rendering,
matching the fix used by BambuStudio
- Enable the 20-second timeout fallback in load.js so the wizard
proceeds even if the C++ -> JavaScript signal fails
HanifKoh