Firefox gets "ReferenceError: Â is not defined" in unminified moxie.js

[kinggmobb]

In unminified moxie.js, there exists some weird Unicode characters on line 7391, between the BinaryReader constructor fn and the call to Basic.extend(). In a hex editor, you can see the character bytes are "C2A0", which is a random Korean Hangul character in Unicode.

In Firefox (as of the latest 117), when using Divi, this causes an exception when loading unminified moxie.js. Firefox's Js loader interprets the first byte alone as Â, and fails while loading moxie.js.

I can replicate this in FF+Divi, but the problem does not appear in Chrome, Safari, or in FF when using other builders like Classic/Gutenberg/Elementor/Beaver. Minification strips out the problem bytes.

This link, ​https://stackoverflow.com/a/1462039/1201409, suggests the error is leftover from an earlier era of encoding a nonbreaking space before UTF-8 replaced other encodings.

Regardless of how the bytes got in there (and whether FF/Divi have bugs), they shouldn't be there, and luckily, the fix is trivial: delete them.

[kinggmobb]

moxie.js error in Firefox console

[kinggmobb]

Hex editor view showing the relevant bytes

[kinggmobb]

Patch

[jorbin]

Welcome to trac @kinggmobb and thanks for the report. While you are seeing this error in WordPress, plupload is not a library that WordPress maintains.

Can you report this upstream to ​https://github.com/moxiecode/plupload and then when there is a new release WordPress can update to that?

I'm adding the close tag so that after it is reported upstream, we can close this as reported-upstream

[kinggmobb]

I was prepping to file a bug upstream, but then I took a closer look at the plupload and moxie repos.

I ran a git bisect, and turns out, the bug was silently introduced, and then inadvertently fixed, 7 years ago. WordPress is just using an ancient version of moxie.js from that time window. (There's a reference to the message I saw in ​https://github.com/moxiecode/moxie/issues/144, but I don't think anyone realized the error at the time.)

The issue was fixed right before moxie v1.5.0, in commit b9f329e1add1e19752263fe62a6b7d993bbd1906.

I think if WP upgrades to a moxie version from v1.5.0 on, it should fix the problem. Alternatively, my patch is trivial if you don't feel like upgrading moxie.js.