fix: Handle unicode in webview events.

[tdomhan]

The request header does not support unicode characters leading to Type: error when calling setRequestHeader with a non-ascii string. This PR first encodes the data using base64 before setting the header. The downside is that this increases the content size by 33%.

This addresses #3125

Running the build updates all Javascript files. I assume this is due to the Typescript version. I'm using 5.7.2. Let me know if I should be using a specific version.

[jkelleyrtp]

Wow, thanks for the quick fix! Do we need to do base64 encoding? Is there a chance that our mime-type is just not set properly on the XHR request that we can fix by using text/plain;charset=UTF-8 as the mime-type?

[tdomhan]

I'll double check. In my initial attempts I wasn't able to get this work without the base64 workaround, but indeed if this could be avoided that'd be great and I hadn't changed the mime-type yet.

[tdomhan]

I tried setting the mime type to text/plain;charset=UTF-8 but run into the same issue. From what I'm gathering this would only affect the body and the header only allows ISO-8859-1.

[jkelleyrtp]

Ah good point, we had to switch to the header from the body since wry was stripping the body on android. I'll check and see if that's still the case...

[tdomhan]

Were you able to test whether this can be moved back to the body or would it be ok for the time being to move to base64?
Potentially base64 could also be restricted to the header and Android and in the receiving part we could check whether the header exists and decode as base64 and otherwise use the body. What do you think?

[jkelleyrtp]

Were you able to test whether this can be moved back to the body or would it be ok for the time being to move to base64? Potentially base64 could also be restricted to the header and Android and in the receiving part we could check whether the header exists and decode as base64 and otherwise use the body. What do you think?

It seems simpler to use base64 encoding everywhere instead of excluding android. We'd need some way to tell the interpreter that it needs to use one vs another. Since this is just for event handling, I don't think there will be too much performance overhead.

If the performance starts to bite us then we can look at using bodies everywhere but android.