Soft hyphen is being included in a copy and paste clipboard operation
Reported by
wil...@easymarkit.com,
Sep 22 2017
|
||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.91 Safari/537.36 Steps to reproduce the problem: 1. a) Copy this regular expression: ([\d]+)$ OR b) Copy this regular expression using Ctrl+A if a) doesn't work: http://rubular.com/r/M58qyBfuxF (note that the regular expression should be matching the numbers at the end of the strings, but is not. Press the delete key with the cursor set after the dollar sign and observe the expression matching correctly) 2. Paste the expression in a text box What is the expected behavior? It is expected that an invisible character is not included with the copy paste operation. Or, it is expected that the character would be visible in a field that accepts user input. What went wrong? The soft hyphen is included in the copy paste operation, but is not visible. Try pasting the expression in notepad.exe or cmd.exe and note its presence. This seems to occur in macOS as well as Windows: https://i.stack.imgur.com/BwSEW.png (screenshot taken by user who copied and pasted the expression) Did this work before? N/A Chrome version: 61.0.3163.91 Channel: stable OS Version: 10.0 Flash Version: None This was initially discovered when trying to copy a regular expression into Visual Studio Code (runs on Electron, link to filed issue: https://github.com/Microsoft/vscode/issues/34176). The issue seems to present regardless of font used. I was able to reproduce it using Roboto Mono, Lucida Console, and Consolas. Interestingly, some sites seem to scrub the soft hyphen from user submitted text, while others do not. For example, Stack Overflow will include the soft hyphen in copy-pasted text, whereas GitHub does not. This is why I included two parts to step 1 for reproduction. The requested change to this behaviour would be to either ignore the soft hyphen character when copying text, or to include it as a minus hyphen or hyphen character. Possibly related issues: https://bugs.chromium.org/p/chromium/issues/detail?id=40378
,
Sep 25 2017
Tested this issue on 61.0.3163.91 , latest stable 61.0.3163.100 and on latest canary 63.0.3222.0 using windows 10 and Mac 10.12.6 and is reproducible with below steps. Attaching screenshot for reference. 1.Copied text from http://rubular.com/r/M58qyBfuxF and pasted in omnibox -- observed only ([\d]+)$ 2.Now copied text and pasted in terminal and observed ([\d]+)$- This seems to be a Non-Regression issue seen from M-50[50.0.2624.0]. NOTE: 1.In Ubuntu 14.04 on pasting ([\d]+)$ we are seeing ([\d]+)$ with space beside $ sign. 2. Issue is seen on firefox as well
,
Sep 25 2017
Hrm, not sure where it would be appropriate to address this: * Exclude it from selection * Filter when copying * Filter when pasting * Forcibly render when in text boxes Adding a few more components in case anyone has great ideas.
,
Sep 25 2017
Attempted to replicate on a couple more browsers: Microsoft Edge 40.15063.0.0 (Microsoft EdgeHTML 15.15063): 1. Copied the string from http://rubular.com/r/M58qyBfuxF 2. Pasted into the address bar, soft hyphen did not render 3. Pasted into cmd.exe/PowerShell, soft hyphen was present Microsoft Internet Explorer 11 (11.608.15063.0): 1. Copied the string from http://rubular.com/r/M58qyBfuxF 2. Pasted into the address bar, soft hyphen was present 3. Pasted into cmd.exe/PowerShell, soft hyphen was present Oddly, pasting the string into an LXSS (Ubuntu 16.04.3 LTS) Bash (bash --version returns: GNU bash, version 4.3.48(1)-release (x86_64-pc-linux-gnu)) prompt removes the character entirely, no spaces or dashes. It seems as though it's the shell that handles the character, not the terminal program. As for how to handle, respectfully, I'd suggest excluding it from selection. To the best of my understanding, soft dashes are meant to be used by folks creating content for the web; an end user shouldn't really ever know of their existence, especially in scenarios where they'd be pasting text into another program, which would likely have its own hyphenation system.
,
Sep 25 2017
,
Oct 1 2017
A related issue is text-transforms affecting copied content: see issue 325231.
,
Jan 10 2018
,
Aug 21
I was able to reproduce on Chrome Canary 70.0.3528.0 on MacOS. The soft hyphen in the expression ([\d]+)$ (copied from http://rubular.com/r/M58qyBfuxF) was only visible when pasted into terminal.
,
Aug 21
Element#innerText has a same issue and it is tracked by issue 651764 . |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by nyerramilli@chromium.org
, Sep 25 2017