Right click to open inspector does not work when build is generated with -devtools flag only

[goriunov]

Description

Running on latest wails 2.6.0. When build is generated with the devtools only flag, on mac os or windows the right click is still disabled which prevents us from opening inspector.

wails build -devtools

The -debug flag works as expected and has right click enabled to open inspector.

wails build -debug

To Reproduce

1. Create default wails app
2. Run wails build -devtools
3. Start the application and try to open devtools with the right click

Expected behaviour

Right click working and inspector can be opened from the menu

Screenshots

No response

Attempted Fixes

No response

System Details

# Wails
Version | v2.6.0

# System
┌────────────────────────────────────┐
| OS           | Windows 10 Pro      |
| Version      | 2009 (Build: 19045) |
| ID           | 22H2                |
| Go Version   | go1.20              |
| Platform     | windows             |
| Architecture | amd64               |
└────────────────────────────────────┘

# Dependencies
┌───────────────────────────────────────────────────────┐
| Dependency | Package Name | Status    | Version       |
| WebView2   | N/A          | Installed | 114.0.1823.82 |
| Nodejs     | N/A          | Installed | 18.14.2       |
| npm        | N/A          | Installed | 9.5.0         |
| *upx       | N/A          | Available |               |
| *nsis      | N/A          | Available |               |
└─────────────── * - Optional Dependency ───────────────┘

# Diagnosis
Optional package(s) installation details:
  - upx : Available at https://upx.github.io/
  - nsis : More info at https://wails.io/docs/guides/windows-installer/

 SUCCESS  Your system is ready for Wails development!

Additional context

No response

[mmghv]

The -devtools flag actually enables the right-click menu, but after adding the EnableDefaultContextMenu option, and smart default context-menu functionality the default behavior of the context-menu changed so it only shows for text contexts (in inputs or when text is selected), you can test this by right clicking in the input, context-menu will show along with the inspect option.

We have two options to solve this :

1- Using the -devtools flag enables the default context-menu everywhere (like in dev and debug), but then EnableDefaultContextMenu option and its different settings will have no effect when -devtools is used.

2- Keep it as it is, and if the dev wants the context-menu everywhere, he will have to set --default-contextmenu: show; style on the page body, but this is a little confusing as this is a setting for EnableDefaultContextMenu option.

Either ways, some updates to the docs will be needed to make this clear

I'm honestly not sure what is the right solution here, @goriunov, @leaanthony What do you think?

[goriunov]

TBH I am leaning towards the second option. We just need to update documentation on the -devtools flag that we should enable the default context menu to be able to access the inspector, it somewhat makes sense. @leaanthony what do you think?

[leaanthony]

Rather than get bogged down in different scenarios, how about we add WindowOpenDevTools() to the runtime and have it disabled in production builds? That way you can open it using a shortcut or clicking on something in the page.... Thoughts? It would negate the need for the devtools flag.

[mmghv]

@leaanthony It sure is a useful thing to add, but IMHO it's something different than -devtools and it has its own problems as discussed here

Mainly that it requires private APIs for Mac, in windows it works as tested without the devtools being enabled (so can be a hidden option), but in Linux the devtools has to be enabled to be able to open it programmatically.

and have it disabled in production builds?

The main use case for the devtools option is in production builds, in dev and debug you already have access to it.

Why -devtools is still a needed option even with WindowOpenDevTools()? because on Mac -devtools doesn't require private APIs, in addition it's sometimes useful to have the familiar inspect context menu enabled, so both options are uniquely viable, so we still need to figure out -devtools.

[mmghv]

@goriunov

TBH I am leaning towards the second option

Me too, but I think if we go this route then it would make more sense to require EnableDefaultContextMenu option along with its setting, so -devtools only adds the inspect command on the context-menu, but doesn't implicitly enable the context-menu, so you will have to enable EnableDefaultContextMenu and choose to leave the auto functionality or add the CSS to show the conetxtmenu everywhere.

[leaanthony]

I still think your original suggestion of having a runtime method is perfectly valid. The more I've thought about it, the more I think that it's fine to let the developer choose. We can warn that the use of private APIs will not pass app store guidelines. All of this could be default in a !production build and disabled in production build?

[leaanthony]

I've got a PR up to add F12 hotkey on all platforms to open the devtools window when compiling with the devtools flag.
If you are unsure how to test this, please follow this guide. Let us know how you get on 👍

[goriunov]

Sorry for late reply, got a bit swamped, F12 sound good! Just did a test on Mac and Windows from latest master branch and everything seems to work well!