[wp-trac] [WordPress Trac] #55117: Possible 5.9 Bug: Unknown character ( or %ef%bf%bc ) on content title

[WordPress Trac]

#55117: Possible 5.9 Bug: Unknown character ( or %ef%bf%bc ) on content title
-------------------------------------------------+-------------------------
 Reporter:  cantuaria                            |       Owner:  audrasjb
     Type:  defect (bug)                         |      Status:  assigned
 Priority:  normal                               |   Milestone:  6.1
Component:  Permalinks                           |     Version:  5.9
 Severity:  normal                               |  Resolution:
 Keywords:  has-testing-info has-screenshots     |     Focuses:
  has-patch needs-testing                        |
-------------------------------------------------+-------------------------

Comment (by ironprogrammer):

 == Testing Instructions (Updated) ==
 In my local testing, these steps demonstrate the unintended appending of
 the [https://apps.timwhitlock.info/unicode/inspect?s=%EF%BF%BC object
 replacement character] at the end of a published post slug. The issue was
 reproducible when creating a new post using **Chrome**, but I was unable
 to reproduce the problem in Safari or Firefox. More test reports are
 welcome!

 These instructions supersede the [#comment:24 previous testing
 instructions], and focus only on the unexpected effect of this character
 on published post slugs.

 > 💡 **Good to Know:** In Chrome, the "object replacement character" will
 appear as a "blank" space, both in the address bar and in page content.
 However, in Safari and Firefox the same URL will appear with the character
 URL-encoded as `%ef%bf%bc`.

 > 💡 **Also Good to Know:** How the cursor enters the title field matters.
 See the **Additional Information** section for more information.

 ''Preparation and reproduction updates have been adapted from
 [https://github.com/WordPress/gutenberg/issues/38637#issuecomment-1172406137
 related testing by @dmsnell].''

 === Steps to Reproduce (Chrome) ===
 1. Create a Google Doc with two lines of text, separated by a single line
 break. This is the source document.
 2. On your WordPress site, in WP admin navigate to ''Posts > Add New''.
 3. Switch back to the Google Doc, and select and copy the first line. Be
 sure to highlight the entire line, including the "blank" space that
 represents the line break at the end of the line. **See Figure 1.**
 4. Switch back to the ''New Post'' screen.
 5. Click in the title field. ''See Additional Information below for why
 this matters.''
 6. Paste in the copied text from the Google Doc.
 7. Click **Publish** (and **Publish** again if pre-publish checks are
 enabled).
 8. 🐞 Click **View Post** and observe in the address bar that the slug
 name ends with a hyphen and what appears to be a blank space (e.g.
 `.../test-trac-55117- /`).
 9. 🐞 Copy the address from Chrome and paste it into the address bar of
 Safari or Firefox. Observe that instead of a blank space, the slug ends
 with "`-%ef%bf%bc`" (e.g. `.../test-trac-55117-%ef%bf%bc/`). (After
 pressing Return in the address bar, the browser may capitalize the encoded
 character sequence to "`-%EF%BF%BC`".)

 === Expected Results ===
 - ✅ The saved post slug should not end with the object replacement
 character (``), whether displayed as a blank (Chrome) or encoded (Safari
 and Firefox).

 === Supplemental Artifacts ===
 [[Image(https://cldup.com/De-s4EvRkX.gif)]]
 ''Figure 1.''

 === Additional Information ===
 The editor (or Chrome) appears to treat the pasted text differently based
 on ''how the cursor enters the title field'' 🙃

 To cause the "`[OBJ]`" character to be added to the slug on Publish:
 - Paste after direct navigation to the ''New Post'' page. ''Then select
 the title and **paste again**.''
 - Paste after clicking the arrow keys Down, then Up into field. ''Then
 select the title and **paste again**.''
 - Paste after clicking the arrow keys Right, then Left into field (only
 paste once).
 - Paste after clicking the field (only paste once). ''Not shown in video,
 but resembles selecting and pasting again.''
 - Paste after switching from another tab/window (only paste once).

 The last two scenarios perhaps most closely resemble the use case
 underlying reports of this issue.

 See this demonstration video for more detail:
 https://cloudup.com/cDHHsWDLofx.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/55117#comment:29>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform