-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[v2, options] Add EnableDefaultContextMenu option #2733
[v2, options] Add EnableDefaultContextMenu option #2733
Conversation
Tested on wails doctor
@leaanthony Please test on |
Yes, same on Windows & Linux, also there's a menu to save the website HTML, it would be a tradeoff, for me for most of the use cases I'll use Wails for, it's totally worth it to add the copy/paste menu which is essential IMO for inputs to the end-users, adding a custom copy/paste is somewhat hacky with JS, for critical apps you would disable it and add your custom solution. Maybe in the future we could disable some of the menu items if that's something the webview supports, for now that's more than good enough for many use cases. |
Also a quick fix would be for the developer to disable the context menu for anything that is not an EDIT document.oncontextmenu = function(e) {
// Allow context menu on any input
if (e.target && ['INPUT', 'TEXTAREA'].includes(e.target.tagName)) {
return;
}
// Allow context menu on any text selection
if (window.getSelection().toString()) {
return;
}
// Disable the context menu otherwise
e.preventDefault();
} Tested on Windows & Linux @leaanthony Ready for review. |
Did you try that out? I'm unsure if hooking into the context menu event will actually prevent the native one showing. If it does, then one strategy is to do something similar to how drag works: you could have an attribute like |
That's great! I think having an html attribute to control this may be pretty cool then. If I'm right, this can be added after this PR with no breakages... |
I think so, but having a broader solution that just works is easier for the developer, or do you mean adding the broader solution + HTML attributes for custom elements? |
@mmghv - any chance you could do a |
Yeah, it's just something we add on top to this rather than having each dev doing JS hacks. |
I think you're right, adding the HTML attribute option would give the developer a fine control out of the box, while having the option to implement the broader solution himself, we could also put it in the documentation because I suspect most would just do that. I'll work on a PR right after this one. |
You're on 🔥 |
…ithub.com/mmghv/wails into feature/enable-default-contextmenu-option
Done, can you re-trigger the tests? |
Nice one @mmghv 🙏 |
Description
This PR adds the option
EnableDefaultContextMenu
which enables the browser's default context-menu in production. This menu is already enabled in development, as well as in debug builds and production builds with the-devtools
flag.Note: It's disabled by default so the default behavior is not changed.
Note: Enabling this option alone doesn't include the devtools
Inspect
menu.Reference issues :
#2438
#1835
Screenshot
Type of change
How Has This Been Tested?
Here's how to test it :
1- Create a new project
wails init -n testproject -t vanilla
2- Follow these instructions (replace
[IDofThePR]
with2733
), and make sure to add the replace directive in go.mod.3- Change
testproject/main.go
to add this option :Expected behavior
wails build -debug
andwails build -devtools
, the context-menu should be available with the devtools inspector whetherEnableDefaultContextMenu
istrue
orfalse
.wails build
, the context-menu should ONLY be available whenEnableDefaultContextMenu
istrue
, and the devtools SHOULD NOT be present in the menu.Test Configuration
wails doctor
Checklist:
website/src/pages/changelog.mdx
with details of this PR