Fix intermittent startup crash on Windows: honor disableHttpsFeatures in Welcome Tab

[SatyamAgarwl]

Problem

On Windows 11, Robo 3T 1.4.4 intermittently crashes ~30–60 seconds after startup. It typically takes 4–5 launch attempts before an instance stays open. The Windows Event Log shows the same signature every time:

Faulting application name: robo3t.exe, version: 1.4.4.0
Faulting module name: Qt5WebEngineCore.dll, version: 5.12.8.0
Exception code: 0xc0000005 (EXCEPTION_ACCESS_VIOLATION)
Fault offset: 0x0000000002cde680

Crash-dump analysis shows the faulting thread entirely inside Qt5WebEngineCore.dll (Chromium 69) during embedded-browser startup — a timing race between the bundled 2018-era Chromium and current Windows builds.

Investigation

The crash is triggered purely by the Welcome Tab's QWebEngineView starting the embedded Chromium. In 17 instrumented launches, the crash reproduced regardless of every external mitigation:

• clearing the QtWebEngine cache/profile (%LOCALAPPDATA%\robo3t)
• QTWEBENGINE_CHROMIUM_FLAGS: --disable-gpu, --no-sandbox, --disable-http-cache, --proxy-server blackhole, --host-resolver-rules blocking the feed host
• "disableHttpsFeatures": true in robo3t.json
• Windows 8 compatibility mode

disableHttpsFeatures=true not helping is the notable one: MainWindow.cpp gates the Welcome Tab menu action on this setting, and the Linux implementation of WelcomeTab honors it too — but the Windows/macOS implementation creates the QWebEngineView unconditionally, so the embedded Chromium always starts and the setting cannot prevent the crash.

Fix

Make the Windows/macOS WelcomeTab respect disableHttpsFeatures, consistent with the menu action and the Linux implementation: when the setting is enabled, skip creating the QWebEngineView entirely. No WebEngine object is ever instantiated, so the embedded Chromium never initializes and the crash cannot occur. Users hitting this crash get a working opt-out (Options → Disable HTTPS features, or "disableHttpsFeatures": true in robo3t.json).

The Welcome Tab simply renders empty in that case, matching the existing intent of the setting.

Note: I don't have a Qt 5.12/MSVC build environment to produce a Windows binary, so this is compile-untested but mirrors the exact AppRegistry::instance().settingsManager()->disableHttpsFeatures() usage already present in MainWindow.cpp and the Linux section of this same file.