Bug 50736

Summary: Unable to paste in input[type="text"] with last-child selector
Product: WebKit Reporter: rikard
Component: HTML EditingAssignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Normal CC: abarth, adele, ap, darin, enrica, eric, matiasnu, ojan, rniwa, tkent, tony, webkit.review.bot
Priority: P2 Keywords: HasReduction
Version: 528+ (Nightly build)   
Hardware: All   
OS: All   
Attachments:
Description Flags
For chrome 8 and Safari 5
none
For chromium
none
Two input fields to demonstrate that the first field works as expected
none
adds regression tests ojan: review+

rikard
Reported 2010-12-08 23:54:34 PST
The last-child css selector will in some way interfere with paste in Chrome 8,Safari 5 and Chromium. It is not possible to paste text into a textbox that has existing data in it if the :last-child selector is present on the page. This works better with Chromium but the problem still exists in some cases. See attachements.
Attachments
For chrome 8 and Safari 5 (373 bytes, text/html)
2010-12-09 00:00 PST, rikard
no flags
For chromium (398 bytes, text/html)
2010-12-09 00:01 PST, rikard
no flags
Two input fields to demonstrate that the first field works as expected (387 bytes, text/html)
2011-01-14 02:22 PST, Matias
no flags
adds regression tests (4.37 KB, patch)
2011-03-09 14:35 PST, Ryosuke Niwa
ojan: review+
rikard
Comment 1 2010-12-09 00:00:02 PST
Created attachment 76020 [details] For chrome 8 and Safari 5
rikard
Comment 2 2010-12-09 00:01:04 PST
Created attachment 76021 [details] For chromium
Matias
Comment 3 2011-01-14 02:22:04 PST
Created attachment 78916 [details] Two input fields to demonstrate that the first field works as expected It's only the last input field that is affected as you can see from the new attachment but It gets even weirder; 1) Select part of the word Chrome. 2) Paste in first field works. Paste in last field does not work. 3) Select the whole word Chrome by double clicking it. 4) Both first and last field pasting works!
Matias
Comment 4 2011-01-14 02:34:37 PST
The chromium attachment seems to work as expected in Chromium 10, so it's possible all issues have been fixed.
Ryosuke Niwa
Comment 5 2011-03-09 14:07:43 PST
Confirmed that this bug reproduces on Safari 5 but doesn't reproduce on TOT.
Ryosuke Niwa
Comment 6 2011-03-09 14:35:41 PST
Created attachment 85237 [details] adds regression tests
Ojan Vafai
Comment 7 2011-03-10 00:18:27 PST
Comment on attachment 85237 [details] adds regression tests View in context: https://bugs.webkit.org/attachment.cgi?id=85237&action=review > LayoutTests/editing/input/div-first-child-rule-input.html:11 > +// The bug only reproduces on Safari 5 when input is the last element in body Nit: mentioning a specific Safari version is not useful. All layout tests only reproduce in some previous Safari version. Just because this test was committed after doesn't change what the comment should say. All I'm saying is s/on Safari 5//. > LayoutTests/editing/input/div-first-child-rule-textarea.html:11 > +// The bug only reproduces on Safari 5 when textarea is the last element in body Ditto > LayoutTests/editing/input/div-first-child-rule-textarea.html:22 > + if (input.value == 'hello world') > + input.parentNode.insertBefore(document.createTextNode('PASS'), input); > + else > + input.parentNode.insertBefore(document.createTextNode('FAIL'), input); While I'm nitpicking, it would be more readable to do: var success = (input.value == 'hello world') ? 'PASS' : 'FAIL'; input.parentNode.insertBefore(document.createTextNode(success), input);
Ryosuke Niwa
Comment 8 2011-03-10 10:59:42 PST
Thanks for the review! Will fix both issues before landing it.
Ryosuke Niwa
Comment 9 2011-03-10 11:22:59 PST
WebKit Review Bot
Comment 10 2011-03-10 16:40:15 PST
http://trac.webkit.org/changeset/80737 might have broken GTK Linux 32-bit Debug and GTK Linux 64-bit Debug The following tests are not passing: fast/js/large-expressions.html jquery/effects.html
Note You need to log in before you can comment on or make changes to this bug.