element-x-ios icon indicating copy to clipboard operation
element-x-ios copied to clipboard

Copy-pasting text on macOS picks up nonprinting RTL unicode, causing confusion

Open ara4n opened this issue 5 months ago • 2 comments

Steps to reproduce

  1. Drag over some content in EXI on macOS to select it and copy it for pasting elsewhere
  2. Paste it somewhere else (e.g. into the composer)
  3. Discover that you accidentally copied a bunch of nonprinting unicode characters like <0x2066><0x2004><0x2004><0x2004><0x2004><0x2004><0x2004> (RTL OVERRIDE and THREE-PER-EM spacing)
  4. Watch chaos like https://github.com/element-hq/element-web/issues/30351 ensue

Outcome

What did you expect?

I'm surprised that we have a bunch of non-printing unicode clogging up our bubbles, unless the text present really is a combo of RTL & LTR or similar. The three-per-em-spacing thing looks particularly weird, as if it's being used for layout. Surely these shouldn't be picked up by the clipboard.

What happened instead?

Clipboard gets polluted with non-printing unicode.

Your phone model

No response

Operating system version

macOS 15.5

Application version

969

Homeserver

matrix.org

Will you send logs?

No

ara4n avatar Jul 21 '25 10:07 ara4n

The 0x2066 is presumably coming from https://github.com/element-hq/element-x-ios/blob/develop/ElementX/Sources/Other/Extensions/LayoutDirection.swift

and the 0x2004 from https://github.com/element-hq/element-x-ios/blob/develop/ElementX/Sources/Other/Extensions/String.swift#L55

ara4n avatar Jul 21 '25 10:07 ara4n

Yeah, exactly. This is the solution we came up with to reserve the space in the bubble for the timestamp etc without having to always put it on a new line. My understanding is that we couldn't use exclusionPaths at the time due to an issue with TextKit 1 vs 2.

pixlwave avatar Jul 21 '25 12:07 pixlwave