Emojis in input to fill-human appear as ?? in the target input element

[tupini07]

Version
[etaoin "1.0.40"]

Platform
Operating System: Tested on Windows 11 and WSL
Clojure version: [org.clojure/clojure "1.11.1"]
Leiningen: 2.10.0
JDK vendor and version: Java 19.0.2 OpenJDK 64-Bit Server VM

Tried with Firefox under WSL
Browser vendor: Firefox
Browser version: 112.0.2
WebDriver version: geckodriver 0.33.0 (a80e5fd61076 2023-04-02 18:31 +0000)

Also tried with Chrome under Windows
Browser: Chrome
Browser version: 112.0.5615.49
WebDriver version: ChromeDriver 112.0.5615.49 (bd2a7bcb881c11e8cfe3078709382934e3916914-refs/branch-heads/5615@{#936})

Symptom
If I ask etaoin to fill-human using a text that contains emojis, those emojis will get rendered as ?? instead of the actual emoji characters.

Interestingly, this does not happen when using fill. Meaning that when using fill the emojis appear correctly in the target input.

Reproduction

  (require '[etaoin.api :as e])
  (def driver (e/firefox))
  (e/go driver "https://google.com")
  (e/fill-human driver ".//textarea[@name='q']" "😐🍃🍂 hello")

Actual behavior
I don't see the emojis in the target text area, instead they appear as ??. Here's a screenshot of what I get when I run the Reproduction code.

Expected behavior
I would expect the emojis to appear correctly instead of ?? when using fill-human

Diagnosis
I'm not sure why this might be happening, but the fact that fill works and fill-human doesn't makes me think that maybe "fill-human" is having issues with the fact that emojis are multi-byte characters?

Action
I could help with this but first I wanted to have some other opinions. Maybe there's a way to use fill-human with emojis without having to change the code.

[lread]

Huh, interesting @tupini07, thanks for reporting. (A most excellently written issue, thanks!)

The fill-human fn is an Etaoin invention (as opposed to part of the WebDriver spec) so probably an Etaoin bug.

Investigation + PR welcome.

[lread]

@tupini07 I just noticed Windows in your description so thought I'd better try this on another OS. I can replicate what you see on Linux, I'm on Pop!_OS.

JDK 17.0.7 temurin
Firefox 112.0.1 + GeckoDriver 0.33.0
Chrome 112.0.5615.165 + ChromeDriver 112.0.5615.49

[tupini07]

I was looking a bit into this and it seem the original assumption was correct. When doing a normal doseq it won't consider "wide" unicode characters. Example

(seq "t😐h🍂s o👻r")

;> (\t \? \? \h \? \? \s \space \o \? \? \r)

I saw that there's a String.codePoints function that we can use to get the codepoints as ints directly, then it's just a matter of converting those back to strings 🙂

(map #(Character/toString %)
     (-> (.codePoints "t😐h🍂s o👻r")
         (.toArray)))

;> ("t" "😐" "h" "🍂" "s" " " "o" "👻" "r")

If there's no rush then I'll make a PR with this change at some point tomorrow or during the weekend :)

[lread]

Huh, I did not realize/remember this nuance when using seq on strings!

We'll have to remain babashka friendly too.
This strategy seems to work in both clojure and bb:

user=> (->> "t😐h🍂s o👻r" .codePoints .iterator iterator-seq (map #(Character/toString %)))
("t" "😐" "h" "🍂" "s" " " "o" "👻" "r")

Looking forward to your PR!