RESOLVED FIXED 60830
Mouse-select then Cut, results in preceding character being lost
https://bugs.webkit.org/show_bug.cgi?id=60830
Summary Mouse-select then Cut, results in preceding character being lost
PAC
Reported 2011-05-13 22:53:03 PDT
Initially reported as a Chromium bug, I have been asked to post to webkit buglist.... Chrome Version : 11.0.696.68 OS Version: OS X 10.6.7 Other browsers tested: Safari 5.0.5 (6533.21.1): FAIL Chromium 11.0.692.0 (77020): FAIL Firefox 4.x: OK What steps will reproduce the problem? 1. Load any webpage with a <TEXTAREA>, lets use http://www.w3schools.com/tags/tryit.asp?filename=tryhtml_textarea 2. Using the mouse, double click any word. Lets use 'because' as an example.. 3. Press CMD-X to cut 3. Press CMD-V to paste it back again What is the expected result? 'because' is cut into the clipboard, leaving the rest of the text intact Pasting the word back should result in the original text again What happens instead? 'because' is cut into the clipboard, but the preceding character (in this case a space) disappears completely (and isnt in clipboard). This happens no matter what the preceding character is, even if its a carriage return. The same problem does *not* occur if you use the keyboard to select the word, and then cut.
Attachments
Patch (17.25 KB, patch)
2012-08-08 17:43 PDT, Sukolsak Sakshuwong
no flags
Patch (17.61 KB, patch)
2012-08-08 18:26 PDT, Sukolsak Sakshuwong
no flags
Patch (18.66 KB, patch)
2012-08-09 15:55 PDT, Sukolsak Sakshuwong
no flags
Mehmet
Comment 1 2011-05-13 23:04:02 PDT
Alexey Proskuryakov
Comment 2 2011-05-14 11:27:08 PDT
> 'because' is cut into the clipboard, leaving the rest of the text intact Why do you expect that? It's intentional that extra spaces are removed, it's called "smart cut&paste". TextEdit has the same behavior. > Pasting the word back should result in the original text again Here, WebKit clearly has a bug. Pasting should be smart too!
Sukolsak Sakshuwong
Comment 3 2012-08-08 17:43:51 PDT
Ryosuke Niwa
Comment 4 2012-08-08 17:47:40 PDT
Comment on attachment 157351 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=157351&action=review > LayoutTests/editing/pasteboard/smart-paste-in-text-control-expected.txt:3 > +Hello world test It's not obvious when the test is passing. Can we print out PASS/FAIL based on the results? > LayoutTests/editing/pasteboard/smart-paste-in-text-control.html:14 > +This tests smart pasting in a text control. There are three words in the text area below, i.e. "Hello world test". We double click the middle word. Then we cut and paste. It should result in the original text. The space before the middle word should not be lost. You probably want to split this into two lines. We normally mention the part for manual testing by "To manually test, ~~".
Sukolsak Sakshuwong
Comment 5 2012-08-08 18:26:15 PDT
Ryosuke Niwa
Comment 6 2012-08-08 18:39:29 PDT
Comment on attachment 157359 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=157359&action=review > Source/WebCore/platform/mac/ClipboardMac.mm:387 > + pasteboard.writePlainText(text, false); Ugh... can we use enum instead so that these call sites don't look so cryptic?
Sukolsak Sakshuwong
Comment 7 2012-08-09 15:55:44 PDT
WebKit Review Bot
Comment 8 2012-08-09 21:45:39 PDT
Comment on attachment 157569 [details] Patch Clearing flags on attachment: 157569 Committed r125247: <http://trac.webkit.org/changeset/125247>
WebKit Review Bot
Comment 9 2012-08-09 21:45:46 PDT
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.