`gi` + <Tab> to move through input boxes

[int3]

It's difficult to figure out the exact n that matches a given text box. It would be nice if, upon pressing <n>gi, to have a 'mode' where subsequent tab presses cycle through the rest of the input boxes. Once the user starts typing a non-tab key, though, this 'mode' is disabled. Of course this is not going to be a real mode but just an additional layer on the handlerStack. We can visually indicate this to the user by a bordered box around the current input element.

[philc]

Personally I've always just used linkhints for this.

[int3]

I think this is a case of a feature being not nearly good enough to get more user uptake. I use gi all the time as a super-quick way to get to the search box of a website -- I just wish I could use it easily on other textboxes in the page. If we decide to change Vimium's default behavior to not focus on a site's input field, this key combo would become even more useful.

[philc]

I can see why gi would be preferred for very common use cases like google search, but when trying to navigate to the third or fourth text box, I still don't see why gi is substantially better than link hints to warrant your improvement.

Also, how will this improvement work? I imagine the behavior of gi would change, so you'd need to hit "gi[enter]" to focus the first text box, and "gi[tab][enter]" to focus the second?

[int3]

Nope, it'd be gi to focus the first text box. If I then realize that I've focused on the wrong one, hitting tab would move me to the next text box (instead of some random form element on the page.)

[philc]

Ah, makes sense. Reimplementing the browser's normal tab behavior sounds like a bad idea IMO. I'd prefer a more explicit UI, rather than a stateful tab-override which was based on how you got into that text box.

[int3]

More explicit UI: perhaps we could create numeric hints on each text box, so it's clear that you're in a different mode, and it's clear where pressing the tab key will lead you to?

I don't think it's a good idea to override anything other than the tab key, though. Aside from the function keys, tab is the only key whose default behavior isn't to insert characters into the text box.

[int3]

Bump on this. I think I might prototype this tonight.

[philc]

So gi enters another mode? I'm curious to see the UX if you push a feature branch. If we end up adding another mode, it might be worthwhile to refactor the mode management so it's a cleaner change, prior to embarking on this.

[int3]

Prototype pushed. One thing I would like to do, but which is not yet included in the current prototype, is to color the hint of the currently selected input element. Let me know what you think -- I'm personally quite pleased with the result.

I didn't see any problems with the current mode management -- I think the handlerStack works great. I did refactor the link hints code to be more functional, though, so that I could use it in this focusInput mode as well.

[int3]

Update: I've added the coloring of the selected hint as well. The exact color could definitely use some tweaking -- I'm not very good at that. @philc, what do you think of the interface?

[philc]

It looks and works nicely. I admit it is slightly better than linkhints for focusing the 2nd text box on github.com, for example, because fewer elements are highlighted with hints.

I think the UI is kind of confusing. When I enter gi mode the numbers make me believe I can type that number to get to that text box, but I can't. The UI appears similar to numeric linkhints but doesn't work the same way. Our users will adapt, but an inconsistency like this would bug me. What do you think?

The hint aesthetics you picked are nice.

If we go forward with this mode, a minor bug is that shift+tab should work in this mode as well.

[int3]

I think the UI is kind of confusing. When I enter gi mode the numbers make me believe I can type that number to get to that text box, but I can't. The UI appears similar to numeric linkhints but doesn't work the same way. Our users will adapt, but an inconsistency like this would bug me. What do you think?

Perhaps we could have the hints take a different color altogether?

[philc]

Yep, that might help.

Seeing the number next to the textbox doesn't actually help me get to it -- I still need to hit tab a few times. So is it the case that the primary purpose of the hints is to indicate that you're in input-tabbing mode? If so, just showing an overlay over each of the input boxes may be a simpler UI, as it doesn't leverage numbers or hint semantics, and it is similar to Chrome's find UI. What do you think?