Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Can´t get it to work with docs.google.com #71

Open
bdiebold opened this issue Dec 25, 2020 · 6 comments · Fixed by #72
Open

Can´t get it to work with docs.google.com #71

bdiebold opened this issue Dec 25, 2020 · 6 comments · Fixed by #72

Comments

@bdiebold
Copy link

Thanks for your awesome spoon - using it in a lot of apps.

Unfortunately, I have not yet managed to get it run with google docs.
Whenever i enter normal mode, either it does not recognize further keystrokes or switches automatically back to insert mode.

Any idea - or is this a general problem ?
image
@dbalatero
Copy link
Owner

dbalatero commented Dec 25, 2020 •
edited

Hey @bdiebold,

There are a lot of problems with rich input fields like Google Docs. What should be happening is that you enter fallback Vim mode, but it appears that it is actually trying to use the accessibility API + advanced mode here.

It's very odd because it's doing the right thing on my machine. Can you git pull the latest code for the plugin and reload Hammerspoon?

This is the logic that determines whether to try to use advanced mode:

VimMode.spoon/lib/accessibility_buffer.lua

Lines 137 to 145 in f1c740c

function AccessibilityBuffer:isValid()
if self:isBannedApp() then return false end
if not self:getCurrentElement() then return false end
if not self:getSelectionRange() then return false end
if not self:isInTextField() then return false end
if self:isRichTextField() then return false end
return true
end

It's possible this detection is broken/not complete in all cases:

VimMode.spoon/lib/utils/ax.lua

Lines 13 to 27 in f1c740c

axUtils.isRichTextField = function(element)
-- If the current element has any children typically it means there
-- are fancy-ass things in the input element like images, complex HTML,
-- etc.
--
-- from observation, plain text inputs/textareas do not seem to have
-- children.
if not element then return false end
local children = element:attributeValue("AXChildren")
if not children then return false end
return #children > 0
end

@dbalatero
Copy link
Owner

Would something like a URL list be handy?

You could set up URL regexes to set which mode this plugin operates in?

I can get the current URL in Chrome with

tell application "Google Chrome" to return URL of active tab of front window

Safari with

tell application "Safari" to return URL of current tab of window 1

And Firefox appears to just be blowing it:
https://bugzilla.mozilla.org/show_bug.cgi?id=516502

@dbalatero dbalatero mentioned this issue Dec 28, 2020
Merged
@d8b887ab-63f8-4e62-9966-d6e02ed906ff
Copy link

Same here. Exits normal after one keystroke in both docs.google.com and Gmail compose.

10.15.7 / Chrome 88.0.4324.96

diff --git a/lib/vim.lua b/lib/vim.lua
index 9237d4e..9db6eb0 100644
--- a/lib/vim.lua
+++ b/lib/vim.lua
@@ -307,7 +307,8 @@ function VimMode:exitModalAsync()
 end

 function VimMode:canUseAdvancedMode()
-  return AccessibilityBuffer:new(self):isValid()
+  --return AccessibilityBuffer:new(self):isValid()
+  return false
 end

@dbalatero dbalatero reopened this Feb 5, 2021
@dbalatero
Copy link
Owner

@d8b887ab-63f8-4e62-9966-d6e02ed906ff

Does this work for you if you enforce fallback mode for docs.google.com as outlined here?
https://github.com/dbalatero/VimMode.spoon#enforce-fallback-mode-with-url-patterns

@dbalatero
Copy link
Owner

I apologize for the inconsistencies, apps, particularly browsers, have some pretty wild behavior that's really hard to tame easily.

@d8b887ab-63f8-4e62-9966-d6e02ed906ff
Copy link

@d8b887ab-63f8-4e62-9966-d6e02ed906ff

Does this work for you if you enforce fallback mode for docs.google.com as outlined here?
https://github.com/dbalatero/VimMode.spoon#enforce-fallback-mode-with-url-patterns
No

It does work—albeit intermittently—in a freshly-created Chrome profile. Same for a page with just <html><body><textarea></textarea></body></html>.

Thanks for looking into it

@normen normen mentioned this issue Jul 6, 2021
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Add beta feature for forcing fallback modes on certain URLs dbalatero/VimMode.spoon
3 participants
@dbalatero @bdiebold @d8b887ab-63f8-4e62-9966-d6e02ed906ff