Autofocus in input form

[jvican]

Hey, great job @eejdoowad.

I'd like to request a feature that I haven't seen in Saka Key. With vimperator, I can do g + i and it autofocuses to input forms. This is basically a shortcut for f and pressing the hint number for the form.

[eejdoowad]

That's really useful. How does it select among multiple possible form elements?

[jstetten]

It focuses the first input field on the page. Most often this is what is wanted, but you can select subsequent fields by pre-pending the appropriate number key beforehand 2gi, 3gi, etc..

It's a direct analogue from vim and an extremely nice command to have. I use it all the time.

[rleppink]

I miss this greatly in Saka Key. Although I think the way cVim (for Chrome) handles inputs is better than Vimperator/Vimium.

Vimperator/Vimium use the way as described above. The problem is that, yes you can use 2gi or 3gi, but it's not always obvious which input is which number. There are times that there is an input somewhere else on the site that you didn't see, and then you've focused the wrong input.

In cVim you can press i (or whatever you have bound), and it will hint only the input fields in view. Because there aren't that many hints, this usually means that two keystrokes is enough (just as much as g + i), and you get more flexibility in what input you want to focus.

(Ofcourse, you could also have both; a command for selecting the nth input, as well as an input hinting mode)

[rleppink]

I have added an example that works for hinting just inputs. See https://github.com/lusakasa/saka-key/pull/83.

[jstetten]

Great work, @rleppink!

I'd only make two arguments for keeping gi as an option. First, a lot of us vimmers have gi burnt into our muscle memory for inputting; usually it works as desired.

Second, I consider it a feature that 2gi, 3gi, ... have the ability to focus fields that are out of visibility without scrolling. 4gi, for instance, will search reviews on amazon.com product pages no matter where you are on them, which is nice.

Either way, nice work, though.

[eejdoowad]

I ended up going with the selector

'input:not([type=submit]):not([type=button]):not([type=reset]), textarea, select'

and it seems to work well. I also revised hints mode such that it auto activates the target if there is exactly one hintable element. This will be in release 1.25.1, which will be out shortly.

@jstetten, i'm a little confused about what the number prefix is supposed to do. Does it select the nth form element in the document regardless of what is visible in the viewport? Would you expect autoscrolling to the focused element?

EDIT: Looks like I'll have to add :not(type=file)

[jstetten]

Does it select the nth form element in the document regardless of what is visible in the viewport?

Yes, exactly. That was the main reason I spoke up for it. On pages with many frames, it doesn't always work precisely in the order one might predict, but it's usually plenty good enough.

Would you expect autoscrolling to the focused element?

I assumed that Firefox natively scrolled the viewport itself once the input was "clicked", but haven't actually checked Vimperator's code to verify this.

[jstetten]

Just realized a possible source of confusion.

In vim, gi is used solely to insert text. Accordingly, in cVim/Vimperator, gi is restricted to text and textarea input fields, which is why the viewport scrolls automatically to them when selected. Expanding this functionality to radio and button elements is less vim-like, but up to you guys.

Finally, if saka-key does implement gi (in the vim-like manner), would be a bonus to include gI for selecting the last input field on the page.

[eejdoowad]

Autoscrolling to the focused element is definitely not automatic in any browser. If cVim/Vimperator autoscroll, it's because they simulate it. If there's more demand for this command/ a PR, I'll add this command to Saka Key.

If that doesn't pan out, in the long-term it will be possible to implement the command yourself using the Custom Javascript Commands system that's in the works.

The following is a reminder to myself of functionality that should be exposed to custom commands.

1. Find elements using a CSS selector/Javascript predicate
2. Select an element using the number that prefixed the keybinding
3. Scroll the viewport to the selected element

[rleppink]

I ended up going with the selector [..]

Updated to the latest release, and this is working really well! Tested on some sites, and haven't noticed any faulty or incomplete hinting yet. Thanks for the fast turnaround @eejdoowad.

I'd only make two arguments for keeping [..]

Well, those are perfectly valid points. It probably shouldn't be too hard to implement, even with the scrolling (scrollTo(...)). You'd want the selectors to be the same though.

[jstetten]

Autoscrolling to the focused element is definitely not automatic in any browser

How about "auto-jumping" then?

Try this experiment in vanilla Firefox or Chrome. Go to any page with a text or textarea element and click inside it so the insert cursor appears. Without clicking anywhere else, use the scrollbar/mousewheel to scroll the element completely out of view. Now type any key.

You'll find that both browsers auto-jump the viewport to put the input element squarely back into focus so the user can see what they're typing.

No javascript required. This is all I was referring to.