should `fill_in` use `send_keys` internally?

[botandrose]

Heya, just ran into an issue where I was trying to test an autocomplete field, and had to drop down from fill_in to native.send_keys in order for the keyboard events to trigger the autocomplete. This raises the question: any reason not to use send_keys internally for fill_in? I'd be happy to make a PR for this!

[yaauie]

This can be a bit of a minefield, but you're welcome to tackle it; If my memory serves me right, I believe that fill_in currently would be analogous to a focus followed by a paste, while I believe native.send_keys maps over each character and attempts to mimic the pressing of the key or keys needed to make that character, which can have some complicated locale-based edge-cases (e.g., sending an @ character is SHIFT+2 on US-keyboard, but ALT+0 on a french keyboard. I am unsure what the extent of this mapping is – if it is only a few magic characters, or all non-ASCII that get this treatment.

A patch would be welcome, but it would need fairly extensive testing around special characters.

[aprescott]

I think I would expect fill_in to actually have locale dependencies, and simulate real user keyboard interaction. Is there a reason to not go down that road?

[yaauie]

My only reason for not going down that path myself is that I haven't needed it. If you have a need and can solve it with a patch, I'll gladly help shepherd it to merging.

[botandrose]

Great! I'll begin.

[route]

As I remember Jon has already tried to replace this logic with send_keys but faced an issue. There were buggy release and then he switched logic back. You can find out more from git log indeed.