Open devtools through functions.

[Nigel2392]

Is your feature request related to a problem? Please describe.

Sometimes in your production environments; it can be handy to still have an option to open the devtools.
I say; let the developer choose!

Describe the solution you'd like

Through a custom function in the runtime, possibly only allowed to call the function if a specific application configuration setting is set. The setting might seem redundant, but it could keep developers from making mistakes.

This way a developer can implement their own way to enable a simple debug mode in a production environment, without actually running their app in debug.

This could make the life of tech-support employees or developers easier; allowing them to find the root cause of errors more quickly

Describe alternatives you've considered

None. Deploying in a production environment with debug mode is a no-go.

Additional context

No response

[leaanthony]

Hi! This has been implemented on master. Details here: https://wails.io/docs/next/reference/cli#build

[Nigel2392]

I think this has become an issue.

-devtools flag does not exist on my build...

It needs to be specified without the dash. Then it works. The command does not show up in the help menu.

See:

PS C:\Users\Nigel\Desktop\Tickets\tokens\__ideas\desktop_app> wails doctor      
DEB | Using go webview2loader
Wails CLI v2.5.1

 SUCCESS  Done.

# System

OS           | Windows 10 Home
Version      | 2009 (Build: 22621)
ID           | 22H2
Go Version   | go1.20.2
Platform     | windows
Architecture | amd64

# Wails

Version | v2.5.1

# Dependencies

Dependency | Package Name | Status    | Version
WebView2   | N/A          | Installed | 114.0.1823.51
Nodejs     | N/A          | Installed | 18.15.0
npm        | N/A          | Installed | 9.5.0
*upx       | N/A          | Available |
*nsis      | N/A          | Available |
* - Optional Dependency

# Diagnosis

Your system is ready for Wails development!
Optional package(s) installation details:
  - upx : Available at https://upx.github.io/
  - nsis : More info at https://wails.io/docs/guides/windows-installer/

 ♥   If Wails is useful to you or your company, please consider sponsoring the project:
https://github.com/sponsors/leaanthony
PS C:\Users\Nigel\Desktop\Tickets\tokens\__ideas\desktop_app> wails build -devtools .
DEB | Using go webview2loader

  ERROR   Error: flag provided but not defined: -devtools
          See 'Wails build --help' for usage
 ♥   If Wails is useful to you or your company, please consider sponsoring the project:

The following help commands are listed:

Wails build - Builds the application
Flags:

  -clean
        Clean the bin directory before building
  -compiler string
        Use a different go compiler to build, eg go1.15beta1 (default "go")
  -debug
        Builds the application in debug mode
  -dryrun
        Prints the build command without executing it
  -f    Force build of application
  -garbleargs string
        Arguments to pass to garble (default "-literals -tiny -seed=random")
  -help
        Get help on the 'wails build' command.
  -ldflags string
        Additional ldflags to pass to the compiler
  -m    Skip mod tidy before compile
  -noPackage
        Skips platform specific packaging
  -nocolour
        Disable colour in output
  -nosyncgomod
        Don't sync go.mod
  -nsis
        Generate NSIS installer for Windows
  -o string
        Output filename
  -obfuscated
        Code obfuscation of bound Wails methods
  -platform string
        Platform to target. Comma separate multiple platforms (default "windows/amd64")
  -race
        Build with Go's race detector
  -s    Skips building the frontend
  -skipbindings
        Skips generation of bindings
  -tags string
        Build tags to pass to Go compiler. Must be quoted. Space or comma (but not both) separated
  -trimpath
        Remove all file system paths from the resulting executable
  -u    Updates go.mod to use the same Wails version as the CLI
  -upx
        Compress final binary with UPX (if installed)
  -upxflags string
        Flags to pass to upx
  -v int
        Verbosity level (0 = quiet, 1 = normal, 2 = verbose) (default 1)
  -webview2 string
        WebView2 installer strategy: download,embed,browser,error (default "download")
  -windowsconsole
        Keep the console when building for Windows

This is also not completely what I want. Are you sure there is no function to call? I do not mind linking. If there is, what package of the sourcecode might I find it in?

[mmghv]

@Nigel2392 The -devtools flag was just recently added in #2725, This is not released yet, so to test it, you will need to follow these instructions to build using master.

Although, this not exactly what you're asking for, this will show the context menu along with the devtools when you right-click.

I was thinking of adding a runtime function to programmatically open the devtools in production when the devtools/context-menu is not enabled.

I did some testing and I was able to do so on Windows, but on Linux it only worked when the devtools is enabled, on Mac the code that is responsible for opening the devtools is only included in debug mode because it uses private API (I'm not a Mac user/dev so I don't know what's that)

wails/v2/internal/frontend/desktop/darwin/inspector_dev.go

Lines 5 to 6 in 4c7c3d9

	// We are using private APIs here, make sure this is only included in a dev/debug build and not in a production build.
	// Otherwise the binary might get rejected by the AppReview-Team when pushing it to the AppStore.

@stffabi You wrote this code, what do you think? is it not possible to open the devtools on Mac in production? what about Linux, do you know if it's possible when the devtools isn't enabled like in Windows?

[leaanthony]

For context on private APIs: they are APIs that are there, physically callable, but there's no docs and absolutely no guarantees that it will continue working. On top of that, any app that uses one will never pass Apple's app store verification. So it's fine to use if you don't mind it breaking at some point and you're not publishing it.

[Nigel2392]

@Nigel2392 The -devtools flag was just recently added in #2725, This is not released yet, so to test it, you will need to follow these instructions to build using master.

Although, this not exactly what you're asking for, this will show the context menu along with the devtools when you right-click.

I was thinking of adding a runtime function to programmatically open the devtools in production when the devtools/context-menu is not enabled.

wails/v2/internal/frontend/desktop/darwin/inspector_dev.go

Lines 5 to 6 in 4c7c3d9

	// We are using private APIs here, make sure this is only included in a dev/debug build and not in a production build.
	// Otherwise the binary might get rejected by the AppReview-Team when pushing it to the AppStore.

@stffabi You wrote this code, what do you think? is it not possible to open the devtools on Mac in production? what about Linux, do you know if it's possible when the devtools isn't enabled like in Windows?

Ahh, thanks! Did not see it was for a future release, now I do.

I did some testing and I was able to do so on Windows, but on Linux it only worked when the devtools is enabled, on Mac the code that is responsible for opening the devtools is only included in debug mode because it uses private API (I'm not a Mac user/dev so I don't know what's that)

Mind sharing where I can find your concept of opening devtools on Windows/linux through a function call? Sounds interesting!

[mmghv]

Got it, so Mac is out of the question, maybe we could still add this function but it will work according to the platform, if you're on Windows it will always work, on Linux it will work if you build using -devtools or -debug, on Mac it will only work in -debug, what do you think? is it worth it?

[mmghv]

Mind sharing where I can find your concept of opening devtools on Windows/linux through a function call? Sounds interesting!

I'm testing on a local fork of Wails, it's not something you can do in your application code.

[leaanthony]

We could consider a function but it has to be explicitly enabled. But yeah, is there the demand for it vs the complexity of doing it?

[mmghv]

It's not complex at all, it will just be a runtime function that calls an already existing code on each platform.

but it has to be explicitly enabled

It doesn't need an option to enable it, it's just a runtime function, if you need it you call it, say you have an admin area, you can have a button there to open the devtools, it will be most useful on Windows only because you could ship the application with no devtools and still be able to programmatically open in with a password or something.

Edit:
I need to add that most of the work is already done by @stffabi in the code for the option OpenInspectorOnStartup (#2080) that's why it's simple to add this functionality.

[mmghv]

Let's keep this open and if there's more demand for it I could issue a PR.

[leaanthony]

The reason I said "you'd need to enable it" is to ensure that by default it doesn't compile in code that calls private APIs. So we may need to hide it behind a build flag. I'd be interested to know if the code is still in the binary, even if it's not enabled in the config (I doubt the DCE is that good). Can be tested by adding println("I should not be here") in that method then searching for the string in the binary

[mmghv]

It's already hidden behind dev || debug build flag and not included in a production build :

wails/v2/internal/frontend/desktop/darwin/inspector_dev.go

Lines 1 to 6 in 4c7c3d9

	//go:build darwin && (dev || debug)
	package darwin
	// We are using private APIs here, make sure this is only included in a dev/debug build and not in a production build.
	// Otherwise the binary might get rejected by the AppReview-Team when pushing it to the AppStore.

And in production it only includes an empty function :

wails/v2/internal/frontend/desktop/darwin/inspector.go

Lines 1 to 11 in 4c7c3d9

	//go:build darwin && !(dev || debug)
	package darwin
	import (
	"unsafe"
	)
	func showInspector(context unsafe.Pointer) {
	}

So in summary, calling this function in dev or debug would open the devtools, while calling it in production would do nothing and the private APIs won't be included, if I understand correctly (I'm a Go noob after all).

[Plasmatium]

Hey guys, I need this feature. On the production build, I'd like to enter password or other backdoor to open devtools window. This could greatly help on debugging production build