WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
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
Details
Formatted Diff
Diff
Patch
(17.61 KB, patch)
2012-08-08 18:26 PDT
,
Sukolsak Sakshuwong
no flags
Details
Formatted Diff
Diff
Patch
(18.66 KB, patch)
2012-08-09 15:55 PDT
,
Sukolsak Sakshuwong
no flags
Details
Formatted Diff
Diff
Show Obsolete
(2)
View All
Add attachment
proposed patch, testcase, etc.
Mehmet
Comment 1
2011-05-13 23:04:02 PDT
Chromium Bug-Report:
http://code.google.com/p/chromium/issues/detail?id=82603
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
Created
attachment 157351
[details]
Patch
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
Created
attachment 157359
[details]
Patch
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
Created
attachment 157569
[details]
Patch
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.
Top of Page
Format For Printing
XML
Clone This Bug