Comment #3 on issue 60057 by temp01...@gmail.com: Paste doesn't work in
Slashdot replies
http://code.google.com/p/chromium/issues/detail?id=60057
Working fine here. Can you try with a chromium nightly and see it it's
broken there too? It might be a dupe of bug 58110.
Comment #4 on issue 60057 by mkterra: Paste doesn't work in Slashdot replies
http://code.google.com/p/chromium/issues/detail?id=60057
Still broken in 8.0.560.0 (Developer Build 63337). By contrast, pasting at
jsfiddle.net (from Issue 58110) works correctly.
More ballpark FYI: It works correctly in the August 11 nightly, 6.0.492.0
(Developer Build 55850). I can paste consistently, albeit with a slight
lag.
So if I understand correctly, this is the list of revisions between 56647
and 56824 that were also applied to the 6.0.472 branch:
http://build.chromium.org/buildbot/perf/dashboard/ui/changelog.html?url=/branches/472/src&range=56824:56647&mode=html
On second thought, it looks like trunk and branch revisions have different
numbering, so the previous link probably isn't the right range.
Using 7.0.517.41 on XP here. Just wanted to add that in addition to the
textarea, pasting into the "Subject" field tends to fail too.
The problem seems to be specific to the full story pages (eg
http://news.slashdot.org/story/10/10/23/2158243 ) If I paste on a comment
page (even a large one like
http://tech.slashdot.org/comments.pl?sid=1832934&cid=33975442 ) it works
just fine.
If the fields are completely empty, it looks like it works all the times
I've tried, but once there is something in the field, depending on how
large the rest of the conversation is (at more than 1000 comments, pasting
into the textarea when theres something in it fails every time. On a
screen with only 9 comments, pasting never fails.
Now, here's the interesting thing about the failures: If I
write "1234567890" into the textarea and place the cursor at the beginning
of the text area and hit Ctrl-V to paste the word "hello", when Chrome
unfreezes, the cursor has moved to the space between 5 and 6. If I place
the cursor after "1" and press ctrl-V, the cursor moves to the space
between 6 and 7. Clearly something "thinks" that the word hello has been
inserted, and is moving the cursor by the amount of text it "thought" was
inserted. This occurs whether I use Ctrl-V, Shift-Insert, or right click -
paste. If I drag and drop text into the textarea, it works as above but it
seems to try to hilight what it "thinks" was inserted.
Now, here's where things get really weird: While playing with pasting in
different boxes, I noticed in the DOM Inspector that Chrome seems
to "pre-insert" the text as a div at the end of the document,
style="white-space: pre-wrap; -webkit-user-select: text;" So I tried
creating a similar div at the end of the document itself (I was curious to
see if slashdot had some javascript that was detecting the addition of the
div and deleting it before Chrome could finish pasting the text). If I use
the javascript console to do:
document.body.appendChild(document.createElement('div'));
on the story page, then pasting begins to work properly (and quickly). If
I delete the node I created, pasting stops working correctly again.
Gah! there's no preview and no edit, commenting on a bug is worse than
commenting on slashdot!
The bug only affects the main /story/ pages (like
http://news.slashdot.org/story/10/10/24/0019206 ) and /journal/ pages, not
the comments.pl pages. (I incorrectly wrote that it worked fine on "small"
pages, but even small journal pages with no other comments cause the bug).
Pasting into either the comment textarea or the comment subject input fails
when the textarea/input is not empty. If the cursor is placed at the
beginning of the text already in the textarea, it moves to the right by the
number of characters that should have been inserted.
If I use the Javascript console to execute:
document.body.appendChild(document.createElement('div'));
on the story page, then pasting behaves correctly. If I use the DOM
Inspector to remove that node, then pasting returns to the broken state.
I can only trigger this bug if i have a '<' in my text box otherwise
pasting works, but is very very slow, ~1 second for the pasted text to show
up.
running chromium 7.0.544.0 on gentoo. I'll try 8.0.552.11 here later
tonight as well.
Also broken in 8.0.552.215 (Official Build 67652) on Linux.
I actually can't figure out a way to paste into a textarea when this
happens. I usually paste via middle-click -- that doesn't work. Ctrl+v
doesn't work. Pasting into the "value" in the Developer Tools doesn't work.
I actually can't figure out a way to get text into the textarea other than
typing.
Okay... Based on comment 6, and assuming I'm doing this right, the source
of the bug should be one of these changes in the Aug 19 build:
http://build.chromium.org/f/chromium/perf/dashboard/ui/changelog.html?url=/trunk/src&range=56824:56647&mode=html
Further, you can narrow it down to only changes that were ALSO ported to
the 6.x beta branch, since the bug showed up there too. Here's the
changelog for the 6.x beta branch from Aug 19 up through 6.0.472.59 (per
comment 2):
http://build.chromium.org/f/chromium/perf/dashboard/ui/changelog.html?url=/branches/472/src&range=59126:56705&mode=html
Now to look through those two lists for matches...
Comment #16 on issue 60057 by mkterra: Paste doesn't work in Slashdot
replies
http://code.google.com/p/chromium/issues/detail?id=60057
When I go through the beta log and rule out:
- merges that don't come from the dev log's Aug 19 range
- OS-specific stuff (i.e., anything with gtk in the file paths)
- documentation stuff
- minor cosmetic stuff
The leftovers don't look so likely to me :/ Still, CC'ing the devs for:
56753 pkas...@chromium.org
Merge 56737 - Fix numerous alignment problems, both horizontal and
vertical, in drawing the browser chrome.
56768 pkas...@chromium.org
Merge 56766 - Cleanup: Remove dead code, use early returns to reduce
indenting, shorten.
56873 a...@chromium.org
Merge 56795 - Make the extension install UI de-dupe hosts after
disregarding scheme and path.
57072 m...@chromium.org
Reapply: Port r56727 (a...@chromium.org) to the 472 branch. net: expect MITM
attacks with HTTP proxies and command line flag.
Hope you guys have more insight on what might be causing this!
You're likely looking at the wrong things. This is a WebKit issue, not a
Chromium one, so you'd want the WebKit changes for the appropriate time
frames.
Thanks! Looks like the relevant Webkit revision range would be
65615-65726. Aug 19's changes are here:
http://trac.webkit.org/?from=08/19/10&daysback=1&changeset=on&update=Update
And searching the page for "paste" highlights two initial suspects:
http://trac.webkit.org/changeset/65648
http://trac.webkit.org/changeset/65721
Incidentally, I confirmed there's no existing bug report in the Webkit
tracker (searched "paste" and looked through bugs reported after Aug 19).
Comment #19 on issue 60057 by pkas...@chromium.org: Paste doesn't work in
Slashdot replies
http://code.google.com/p/chromium/issues/detail?id=60057
Neither of those commits changes any code.
You need to be careful about how you track down WebKit regressions. Chrome
pulls in particular WebKit revisions in groups, so you need to find the
DEPS changes within your regression range and use those to generate the
WebKit change range.
Dimitri, could you help track down this regression?
Thanks for looking into this! :)
For comment 18, I followed PhistucK's instructions from here:
http://groups.google.com/a/chromium.org/group/chromium-discuss/browse_thread/thread/28114b9b6f2770f1?pli=1
And fed it a few version numbers. For Chrome 7.0.499.0 to 7.0.500.0, I got
Webkit revs 65615-65726*. For Chrome 6.0.472.41 to 6.0.472.51, I got
65411-66079, which swallows the former.
*: More or less; Omahaproxy generated a Chromium rev range of 56643-56799,
which is slightly offset from the comment 6 numbers (56647-56824), so I fed
56643 and 56824 into the DEPS generator for my Webkit range.
Comment #21 on issue 60057 by dgla...@chromium.org: Paste doesn't work in
Slashdot replies
http://code.google.com/p/chromium/issues/detail?id=60057
I gave a quick shot at a reduction and didn't succeed. It _feels_ like
there's an event handler that mucks things up, but the inspector doesn't
show it.
Comment #22 on issue 60057 by temp01...@gmail.com: Paste doesn't work in
Slashdot replies
http://code.google.com/p/chromium/issues/detail?id=60057
Created a testcase.
data:text/html,<style>a:last-child{}</style> <a></a> <textarea></textarea>
Attachments:
slashdot-paste-60057.html 200 bytes
Awesome work, temp01irc! But... it doesn't seem to reproduce the issue for
me? What are the steps?
I can repro the things in comment #10 on that testcase (even the 'inserting
div makes it work' part). Basically, Open > Ctrl+V twice - fails the second
time.
Tested on Windows 7 - another user confirmed on Mac too (using the data
uri).
Comment #25 on issue 60057 by dgla...@chromium.org: Paste doesn't work in
Slashdot replies
http://code.google.com/p/chromium/issues/detail?id=60057
Very interesting. Looks like last-child selector is interacting with
editing. Ryosuke, can you take a look?
I can confirm that on Kubuntu x64 -- reproduces perfectly, including other
ways of pasting (middle-click, etc).
Comment #28 on issue 60057 by temp01...@gmail.com: Paste doesn't work in
Slashdot replies
http://code.google.com/p/chromium/issues/detail?id=60057
Issue 61784 has been merged into this issue.
Comment #29 on issue 60057 by ishe...@chromium.org: Paste doesn't work in
Slashdot replies
http://code.google.com/p/chromium/issues/detail?id=60057
This seems to have been fixed recently.
You need Chrome version 10 of around build 71000 to test this. Chrome 8 is
old news :)
I'm seeing this fixed at least as of 10.0.634.0 (Developer Build 70883) --
probably a bit before then.
There is a lot of lag when pasting, though...
I confirm paste is working consistently (albeit laggy) on Slashdot using
10.0.636.0 (Developer Build 71102) on Windows XP. (Note that the lag isn't
new; it also existed when the paste wasn't working reliably. Only seems to
happen with Chrome on Slashdot.)
Issue 74524 has been merged into this issue.