[QA] Explorer | Loading screen hangs silently with no user-facing error when connecting to a non-loopback local scene dev realm over http

[balducciv]

🛠️ Build version:

Reproduces on both:

• v0.169.0-alpha-bugsweep/aug16-consolidated-22a1a3d (PR fix: bugsweep aug16 #9765, commit 22a1a3d)
• v0.169.0-alpha-main (current production build, via standard launcher)

📔 Issue Description:

When launching Explorer pointed at a local scene dev server on a non-loopback LAN IP over http (e.g. http://192.168.68.127:8000), the client shows a "you are about to enter a custom catalyst" prompt, then the loading screen hangs indefinitely with no further feedback or error message to the user. This reproduces identically on both the PR #9765 build and the current production build (v0.169.0-alpha-main) — confirming it's a pre-existing gap, not something introduced by the bugsweep PR. The underlying blocking mechanism differs by build (see notes below), but in both cases the user is left staring at a frozen loading screen with zero explanation.

👣 STR:

1. Start a local SDK7 scene server (npm run start) so it's reachable on the machine's LAN IP (not just loopback)
2. Launch Explorer with: open ./Decentraland.app --args --realm http://<LAN_IP>:8000 --position 0,0 --local-scene true --debug --scene-console --login-bridge-only
3. Accept the "custom catalyst" prompt and wait on the loading screen

✔️ Expected Result:

Either the app clearly communicates that the connection was blocked/rejected (e.g. an "insecure connection not allowed" message or similar), or it fails fast with an actionable error — not an indefinite silent hang.

❌ Actual Result with evidence:

Loading screen hangs with no error shown to the user. All test sessions were manually force-quit after ~19-21 seconds of no progress.

On PR #9765 build, Player.log shows during asset bundle fetch attempts:

Curl error 35: Cert verify failed. Certificate could not be verified (either omitted or unsupported). UnityTls error code: 7

Occurred 3x per session, across two separate test attempts, immediately preceding manual app quit. Consistent with the new app-level cleartext-scheme enforcement (wearable-mainfile-insecure-url lane, EnforceSecureScheme) upgrading the non-loopback http request to https, then failing TLS handshake since the local dev server has no cert. (Inferred from the TLS failure signature — no EnforceSecureScheme/insecure/cleartext string is directly logged.)

On production build (v0.169.0-alpha-main), Player.log shows instead:

Non-secure network connections disabled in Player Settings

Same silent hang, same lack of any in-app user messaging — this time it's Unity's engine-level insecureHttpOption (still NotAllowed on production) hard-blocking the connection outright.

In both cases, the connection is correctly prevented from silently succeeding over cleartext — not a security bug. The bug is purely the missing user-facing feedback: nothing tells the user why the loading screen is stuck or what to do about it.

➗ Reproduction:

🔁 Always - (3/3 attempts: 2x on PR #9765 build, 1x on production build, same silent-hang result every time)

🖥️ Operative system and additional Notes:

macOS — Apple M3 Pro.

Confirmed pre-existing — reproduces on current production (v0.169.0-alpha-main) as well as the PR #9765 build, so this is not a regression introduced by the bugsweep PR and does not block that PR's merge. Filing as its own item since it's a real UX gap: likely a good candidate to fix as part of the local-scene-development / Creator Hub preview flow specifically, since that's the workflow most likely to hit a non-loopback address in practice.

Player test 1 - wearable-mainfle.log

Player.log

[github-actions]

Automated Triage

Issue type	bug
Affected area	Local Scene Preview / Creator Tools
Feature category	Primary
Severity	SEV-2 → 1-high

Reasoning: This issue blocks a Primary category feature ("Local Scene Preview not Working") for creators developing locally over non-loopback LAN IPs. The underlying security check (blocking cleartext connections) is correct and necessary, but users receive zero feedback when the connection is silently blocked — leaving them staring at a frozen loading screen with no indication of what went wrong or how to proceed. This is 100% reproducible and completely blocks the local scene development workflow for the affected scenario. Per hotfix policy, SEV-2 bugs in Primary categories require a hotfix.

Labels applied: bug, 1-high, Mac Only, ui, sdk

---

Auto-triaged. If labels are incorrect, update issue triage categories or severity policy and re-run triage.