Investigate blank-screen UX when HTTPS loads are blocked by certificate errors

[JSvandijk]

Summary

In emulator testing on April 21, 2026, the app blocked invalid HTTPS loads as intended, but the visible result was still a blank dark WebView instead of a polished explanatory error state.

Evidence

• invalid-cert local HTTPS harness was used from the Android emulator
• the app did not proceed past the TLS failure
• the current UX still needs a clearer visible failure surface

Why this matters

Security controls need understandable user feedback. A blocked certificate load is safer than the previous bypass behavior, but a blank screen can still reduce trust and make support harder.

Next steps

• investigate which WebView callback path is reached on this TLS failure mode
• surface a guaranteed user-facing error card for blocked HTTPS loads
• add an emulator smoke test for this path if practical

[JSvandijk]

Main now includes the broader hardening work from 52a7e5f: the app still blocks invalid TLS, shows clearer connection details, and warns before every HTTP session. I have not rerun the emulator invalid-cert harness in this session, so I am leaving this issue open until that specific blank-screen path is re-verified on-device or in the emulator.

[JSvandijk]

Maintenance check on May 5, 2026 after merging #19 and #20.

Current state:

• MainActivity.java still blocks invalid TLS in onReceivedSslError() and shows a native Certificate warning overlay with retry/diagnostics actions.
• Existing emulator evidence in docs/evidence/v1.1.0-emulator/README.md records the invalid HTTPS blocked state as explicit and user-readable.
• Today's verification covered npm ci, npm test, GitHub node-checks, GitHub android-build, and local cmd /c build-apk.bat.

Keeping this open for one remaining reason: the invalid-cert emulator harness has not been re-run against the exact latest main commit after today's maintenance merges. The code path is still present, but per the repo quality gate the close-out should include current runtime evidence or explicitly say not verified.

Next action: rerun npm run harness:https-bad-cert with the Android emulator and attach the current screenshot/UI dump, then close if the native error overlay still appears.

[JSvandijk]

May 5 follow-up after #21:

I attempted to re-check the invalid HTTPS runtime path, but the attached emulator is currently listed by ADB as emulator-5554 unauthorized. Because the device is not authorized, I could not honestly recapture the latest main runtime evidence for this issue.

Keeping this open. Automated checks and APK build are green, and existing evidence still shows the certificate warning overlay, but current emulator/runtime recapture is not verified.