Mac based browser shortcut fix #4348
Conversation
Various fixes too
…. previously when in the browser on a mac you would have to use the ctrl key to perform keyboard shortcuts which is not intuitive on a mac where cmd is typically used instead of ctrl. this change adds a check in window initialization that will check if the build is browser based (based on build constraints). At runtime there is a javascript check of the navigator.platform value. if this value contains mac, the modifier key handles default shortcut keys with cmd key instead of ctrl key. other operating systems will see no change.
…he code. simplify return logic for mac check.
|
There are other places we assign shortcuts dynamically based on runtime.GOOS. |
|
True, but I think that's a bigger fix as this is internal to the GLFW driver code for the initial fix? |
|
From what I can see the only place that shortcuts are set outside of what I've changed here is in widget/entry.go. But to add this the shortcut fix would have to live outside of the glfw driver. Any suggestions on how to move forward? |
|
I think we will just move forward with this for now as the fix in widget/entry.go would require a new API, which probably should be public, and would wait until 2.5 |
That works for me. Can you please rebase this on the |
|
The other half of this is now landed, so you can update the version this depends on when rebasing and it should be fully testable. |
…. previously when in the browser on a mac you would have to use the ctrl key to perform keyboard shortcuts which is not intuitive on a mac where cmd is typically used instead of ctrl. this change adds a check in window initialization that will check if the build is browser based (based on build constraints). At runtime there is a javascript check of the navigator.platform value. if this value contains mac, the modifier key handles default shortcut keys with cmd key instead of ctrl key. other operating systems will see no change.
…he code. simplify return logic for mac check.
…into browser-shortcut-fix-macos
|
@andydotxyz rebased and updated dependency and set to develop branch. |
|
I'm on windows and ALL shortcuts are broken for me |
You are commenting on a pull request here. Do you mean that with this change it is broken, or it was broken for you before and after? |
After the new update, context menu is working, but still all shortcuts are broken... |
|
This is certainly not the place to report a bug. This is a pull request for fixing shortcuts when running Fyne apps in a browser on macOS. If something isn’t working then please open a bug report instead… |
You tested this PR and it fixed popup menus? That doesn't seem likely. |
Is this the correct PR for my issue, is this related to shortcuts like CTRL + C or CTRL + V or F12 not working? |
|
This should fix all copy-paste shortcuts. When you appply the patch it contains |
Description:
previously when in the browser on a mac you would have to use the ctrl key to perform keyboard shortcuts which is not intuitive on a mac where cmd is typically used instead of ctrl. this change adds a check in window initialization that will check if the build is browser based (based on build constraints). At runtime there is a javascript check of the navigator.platform value. if this value contains mac, the modifier key handles default shortcut keys with cmd key instead of ctrl key. other operating systems will see no change. Note that this does not change custom defined shortcuts. If you define a shortcut as "ctrl+f" it will be interpreted as ctrl+f meaning that even on a mac you will have to use the ctrl key. This would be in line with the expectation that if you were to run a browser based terminal, that ctrl+c wouldn't copy text but would kill the process.
Fixes #(#4301)
This is part 2 of a 2 part fix. Part 1 is in fyne/glfw-js Pull Request 13. Part 1 addresses the clipboard issue in the browser #4301 . Part 2 which is this PR, addresses keyboard shortcuts not working correctly in Mac browsers which was discovered during the testing of the fix created in part 1.
Checklist:
@andydotxyz this is the solution I proposed in glfw-js Pull Request 14. I will now close that pull request.
Thank you.