godbout
Sometimes Vim mode doesn't work for Arc browser
I've encountered a recurring issue with Vim mode functionality within the Arc browser. For example, when I want to use w to move the cursor to the beginning of the next word, it just moves the cursor right, just like what "l" does.
However, there is a temporary fix:
- Click on the kindaVim icon in the Arc browser's menu bar.
- Select "Check what the wizard says".
- Close the wizard window without making any changes.
Post-implementation of this workaround, Vim mode functions correctly for a duration. However, the issue re-emerges after continuous use.
- Click on the kindaVim icon in the Arc browser's menu bar.
- Select "Check what the wizard says".
- Close the wizard window without making any changes.
the temporary fix is just a coincidence. if you don't add Arc in any of kV's Family, then a check of how kV should behave is done at every keystroke. the issue with web browsers is that they're really not consistent. depends on the type of text input/fields etc. lemme have a quick look.
also would help if you let me know where exactly the issue happens. Arc own interface? web page? which web page. etc.
as you can see:
https://github.com/godbout/kindaVim.docs/assets/121373/1f8ee22a-0045-488a-9f2a-8cfe273e0f26
in Arc's UI, the tab thing, kV can use the full macOS AX and it works fine. now in browser pages it doesn't (you can see that in the first two characters in the google search there's a block cursor, that's because for those two characters the macOS AX data is correct. after that it's not and kV has to revert to using key remapping instead of the (wrong) AX data). to get the whole thing consistent, kV tells you to put Arc in the Key Mapping Family (coz i've investigated Arc maybe some months or years ago). then using kV in Arc will be more consistent. still, there may be webpages that override key mapping, like some code editors online etc. in that case yeah, their own overriding will take precedence, unfortunately. Vimming is hard ☹️
I have already put it in Key Mapping family, and the issue only happens in Google Docs and Google search box currently. I've prepared a video demonstration to illustrate the problem.
https://github.com/godbout/kindaVim.docs/assets/95223577/8ff15b09-3152-4cfd-ab12-ed7f0e3f8b02
for Google Docs have a look at this: https://github.com/godbout/kindaVim.docs/issues/34#issuecomment-1010174583 and the rest of the thread. may help for now. will check more.
after i've enabled the AX in Google Docs settings and refreshed the page, then the motions work correctly. can you try?
I tried, but still the same. Also it seems like all input field would have this issue.
https://github.com/godbout/kindaVim.docs/assets/95223577/b44e1d4e-d48e-49ef-9e6b-ad36edb598e6
have you restarted Arc?
works fine here in Google Docs after having specified that it should enable AX, and in all inputs. showing The Wizard is really not gonna help kV do anything. it's a refreshing issue from Arc, maybe:
https://github.com/godbout/kindaVim.docs/assets/121373/53e3abd1-4753-4ffe-bc89-5955c096b0a9
I find a way to reproduce it:
- Put cursor in any input box
- Wait for about 15 seconds
i can reproduce. it's because Arc disables the web pages accessibility elements automatically after a while. why? no fucking idea. it's very clear when i use my other app that highlights AX Elements. video incoming.
https://github.com/godbout/kindaVim.docs/assets/121373/db762555-6f6f-4d24-bc60-fe53ac71bd6c
so:
- after a moment of inactivity, Arc disables the webpage AX. hence kV can't get any information at all
- if you hide Arc and show it again, kV gets Arc to reactivate the AX in the webpage (every time an app becomes the frontmost app, kV checks which app it is and do the necessary to enable the AX)
currently there's two things you can do. one is point 2. when the issue happens, you hide and show Arc again. that's a short term trick coz that's shit in the long term for sure. another way to solve this for now is to add Arc in the 911 Family. in that case kV will not even care whether he can detect any AX at all and will enforce the key remapping everywhere like if everything was an input (coz the Key Mapping Family still uses the AX to determine if we're dealing with some sort of text element, or with any other input like menu, dropdown, etc. but as you see, Arc disable the AX so we can't even know with what kind of element we're dealing with).
for the rest i'll check through Arc's option, and i'll contact the devs.
Thank you so much for taking the time to explain this so thoroughly. It was very helpful.
my pleasure. thanks for using my babies!
i'll contact Arc's devs tomorrow and will update here.
@Celve is it just me or Arc is now exposing its AX Tree constantly? i don't seem to be able to make it fail again.
I can still reproduce this issue after 30 seconds of inactivity on the latest Arc browser. I don’t have the tool to inspect the AX tree.
My arc browser is version is:
- Version 1.74.0 (57065)
- Chromium Engine Version 131.0.6778.205
I can still reproduce this issue after 30 seconds of inactivity on the latest Arc browser.
weird. i don't seem to be able to reproduce anymore lol. or maybe i'm not doing it correctly? will re-read the thread.
ok can reproduce again. forgot that if you moved Arc then it exposes its AX again. it's just so crap lol
actually just even clicking without moving the window works. it's so shit 🤣️
hmm so it seems that i can FORCE the position of the Arc window, positioning AT THE EXACT SAME CURRENT PLACE so that the user doesn't notice anything, and that is enough to reactivate the AX. the thing is, it would already be funky to do for Wooshy or Scrolla by doing something special just for this app when you activate Ws/Sl, but for kV it's even worse to implement. not sure i wanna go down that road to avoid some kinda quirks from Arc itself. i implement stuff in kV/Ws/Sl to make sure most of the edge cases are handled, customizing engines for shit group of apps etc., sometimes even for individual apps, but this is too much. rather than adding a new custom engine for Arc it requires me to kinda change my whole system. so yeah, most surely a no no.
so
- i tried a couple of Arc/Chrome Extensions that are supposed to work with the Accessibility, like Grammarly, ChromeVox, Accessibility Hints, etc. nothing helped. they have access to something (maybe just the DOM?), but the AX Tree is still inaccessible from macOS
- when running VoiceOver (command F5) the AX Tree is accessible at ALL TIMES. so while it's not very conveninent and a proper solution, it tells me that it's possible to keep the AX Tree exposed. but one thing is, i have no idea if it's VoiceOver doing something, or if it's Arc scanning for when VoiceOver is ON. that still gives me a little path to work on. although i had some sort of similar issue with some other apps and i've solved them. now trying with Arc those solutions don't work. so it would seem that it's Arc doing something rather than VO. but i'm still gonna investigate deeper. new road to dig into and grab some new knowledge from.
@Celve do you use Scrolla? planning a release of Scrolla first in the new hours, that should take care of the Arc issue. (releasing Scrolla first coz Apple recommended making changes in my projects but i'm kinda pretty sure the apps are gonna crash on some machines so better make Scrolla crash first lol.)
@Celve do you use Scrolla? planning a release of Scrolla first in the new hours, that should take care of the Arc issue. (releasing Scrolla first coz Apple recommended making changes in my projects but i'm kinda pretty sure the apps are gonna crash on some machines so better make Scrolla crash first lol.)
I don't use Scrolla:) but I would love to help you to test it
no need then :D just in case you were using Scrolla or Wooshy you could have access to the fix first. will release kV last. hopefully in a few days!
@Celve if you use Wooshy then the latest release will make Arc behave, even when using kV: https://github.com/godbout/Wooshy.docs/releases/tag/31
if you're not using Wooshy either, then you'll have to wait still a bit more 😂️ 差不多
support should be improved in kV70: https://github.com/godbout/kindaVim.docs/releases/tag/70
please reopen if you're still having issues.