Hermes Debugger appears to connect but is empty on Flipper 0.55 win in clean RN 0.63.2 project

🐛 Bug Report

Hermes Debugger simply does nothing when connected to a clean RN 0.63.2 project with Hermes enabled on windows. Elements, Console, Sources, Network, Application, etc are all empty of normal content. Doctor passes all tests. Remote debugging is off. No other RN apps running. Verified Hermes running. Android SDK is valid and accessible. All other Flipper functions work fine. There are no problems indicated in the Flipper debug logs.

edit: Sometimes the “Debugging connection was closed” window pops up in the Hermes Debugger. It seems it can be dismissed by clicking outside of it. Pushing “Reconnect DevTools” flashes the window as if refreshing but has no effect.

Debug logs:

(electron) crashReporter.start is deprecated in the renderer process. Call it from the main process instead. 
Secure server started on port 8088 server 
Certificate server started on port 8089 server 
Device connected: TestCleanRNAndroidErrors#Android#sdk_gphone_x86_64_arm64 - 11 - API 30#emulator-5554 server 
{id: 0, method: "getPlugins", params: undefined}
"message:call" 
Device client initialised: TestCleanRNAndroidErrors#Android#sdk_gphone_x86_64_arm64 - 11 - API 30#emulator-5554. Supported plugins: CrashReporter, Databases, Fresco, Inspector, Network, Preferences, React server 

To Reproduce

1. npx react-native init TestApp
2. set enableHermes: true in build.gradle
3. yarn react-native run-android
4. Observe that there is no content in the hermes debugger tab of Flipper and no relevant content in Flipper debug logs indicating any sort of issue.

Environment

• Android API 30 on Android Studio emulator x86_64 google_apis
• React Native 0.63.2 (fresh project, only change is enableHermes: true)
• Flipper 0.55.0
• Windows 10 insider preview build 20206.rs_prerelease_200828-1431

[eltonea]

Working in 0.98.0 starting bundle manually with the command bellow: react-native start --host localhost

[patrickgalbraith]

@mweststrate Looks like this is an issue in metro. I’ve opened https://github.com/facebook/metro/pull/662 which should hopefully fix this by providing a valid IPV6 localhost websocket url.

I had a look at the chrome developer tools source and how it initialises the connection and it is done by creating a new WebSocket(…) and passing the webSocketDebuggerUrl (which makes sense).

As you can see ws://[::] is not a valid url: