Make WordPress Core

Opened 9 months ago

Last modified 8 months ago

#59329 new defect (bug)

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

Reported by: kinggmobb's profile kinggmobb Owned by:
Milestone: Priority: normal
Severity: minor Version:
Component: Upload Keywords: close
Focuses: javascript Cc:


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,, 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.

Attachments (3)

Screenshot 2023-09-12 at 8.05.39 PM.png (1.1 MB) - added by kinggmobb 9 months ago.
moxie.js error in Firefox console
Screenshot 2023-09-12 at 8.07.02 PM.png (167.0 KB) - added by kinggmobb 9 months ago.
Hex editor view showing the relevant bytes
59329.diff (377 bytes) - added by kinggmobb 9 months ago.

Download all attachments as: .zip

Change History (6)

9 months ago

moxie.js error in Firefox console

9 months ago

Hex editor view showing the relevant bytes

9 months ago


This ticket was mentioned in Slack in #core by jorbin. View the logs.

8 months ago

#2 @jorbin
8 months ago

  • Keywords close added
  • Milestone Awaiting Review deleted
  • Version trunk deleted

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 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

#3 @kinggmobb
8 months ago

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, 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.

Note: See TracTickets for help on using tickets.