feat: toggle Developer Tools (Cmd+I)#3928
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 09f02c16de
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| fileMenu.AddText("Toggle Developer Tools", keys.CmdOrCtrl("i"), func(_ *menu.CallbackData) { | ||
| if a.ctx != nil { | ||
| runtime.WindowExecJS(a.ctx, `window.webkit.messageHandlers.external.postMessage("wails:openInspector");`) |
There was a problem hiding this comment.
Gate the devtools menu to builds where it works
On macOS release builds produced by scripts/desktop-build.sh (lines 42-49 pass no -devtools/debug tag), this menu item is still shown but the Wails wails:openInspector handler resolves to the production Darwin inspector stub, so File > Toggle Developer Tools / Cmd+I silently does nothing for shipped apps. Please either add the Wails devtools build flag for builds where this should be available, or hide/gate this menu entry to dev/debug builds so the user-facing menu does not expose a dead command.
Useful? React with 👍 / 👎.
esengine
left a comment
There was a problem hiding this comment.
Useful escape hatch — wails:openInspector via the external message handler is the known WKWebView trick for opening the inspector outside dev mode. Worth noting for the record: window.webkit only exists on macOS, so on Windows/Linux this menu entry is a silent no-op (WebView2 users still have their own F12 path in dev builds). Fine as-is for a macOS debugging aid. Merging, thanks!
Add a native menu item "Toggle Developer Tools" (Cmd+I) that opens the WebKit Inspector via
runtime.WindowExecJSwith thewails:openInspectorprotocol.