If the following is true:

  1. Your search form exists on all pages (common for the block form to be in the header of every page, for example)...
  2. ...And someone is on a page with preexisting node/user/entity reference fields (e.g. a node edit form w/one of those types of fields) that uses the autocomplete widget...
  3. ...And someone tries to copy/paste content with CJK characters into the non-GSA autocomplete field in an attempt to reference an entity whose title contains CJK characters...

It's impossible to use core's autocomplete functionality to reference the entity (the autocomplete just never pops up).

Comments

iamEAP’s picture

Status: Active » Needs work
StatusFileSize
new1.96 KB

Here's a patch we're using that just prevents the autocomplete from popping up on pages with preexisting autocomplete fields, but I'm not committing it because it unnecessarily burdens/penalizes sites that probably don't and will never support CJK.

A better patch would either:

  • Fix this module's override of Drupal Core's autocomplete JS to account for copy/paste,
  • Or prevent the checks this patch introduces in situations where only English is used on a site, or when a certain subset of languages are not enabled for a site (e.g. Japanese, Chinese, and Korean).
iamEAP’s picture

The patch in #1 has a small bug that could create false positives in the conflict checker. == vs. ===

iamEAP’s picture

And actually, I would not recommend using either of those patches on production, for anyone who comes along. Memory limits...