Bug 53933

Summary:

Pasting into contenteditable table cell pastes into adjacent cell instead.

Product:

WebKit

Reporter:

santoscordon

Component:

HTML Editing

Assignee:

Nobody <webkit-unassigned>

Status:

RESOLVED FIXED

Severity:

Normal

CC:

cc_lam, dglazkov, emerick, enrica, eric, leviw, rniwa, sukolsak, tony, webkit.review.bot

Priority:

Keywords:

HasReduction

Version:

528+ (Nightly build)

Hardware:

All

OS:

All

Attachments:

Description	Flags
demo	none
Patch	none
Archive of layout-test-results from ec2-cr-linux-04	none
Patch	none

santoscordon

Reported 2011-02-07 12:02:47 PST

Chrome Version : 7.0.517.24 (Official Build 60738) beta URLs (if applicable) : Other browsers tested: Add OK or FAIL after other browsers where you have tested this issue: Safari 5.0.1 (5533.17.8): FAIL Firefox 3.6.10: OK IE 7: OK IE 8: OK What steps will reproduce the problem? 1. Create a content editable table with several cells. 2. Place the cursor after the last character in a non-empty cell. 3. Paste some text What is the expected result? The text be pasted as the last item in the current cell. What happens instead? The text is pasted as the first item in the next cell. Please provide any additional information below. Attach a screenshot if possible. Here is the HTML I used to reproduce this: <html> <body> <div contenteditable="true"> <table> <tr> <td>1</td><td>2</td> </tr> <tr> <td>3</td><td>4</td> </tr> </table> </div> </body> </html>

Attachments
demo (495 bytes, text/html) 2011-03-09 12:04 PST, Ryosuke Niwa	no flags	Details
Patch (2.42 KB, patch) 2012-05-24 20:19 PDT, Sukolsak Sakshuwong	no flags	Details Formatted Diff Diff
Archive of layout-test-results from ec2-cr-linux-04 (458.32 KB, application/zip) 2012-05-24 20:47 PDT, WebKit Review Bot	no flags	Details
Patch (2.42 KB, patch) 2012-05-25 11:19 PDT, Sukolsak Sakshuwong	no flags	Details Formatted Diff Diff
Show Obsolete (1) View All Add attachment proposed patch, testcase, etc.

Levi Weintraub

Comment 1 2011-02-09 14:24:19 PST

I can't reproduce this with Chrome 10.0.648.18 dev nor Safari 5.0.3. It helps to add a border to the table so you can tell which cell you're in, tho I've validated that this has no affect on the ability to reproduce the bug.

Ryosuke Niwa

Comment 2 2011-03-09 12:04:14 PST

Created attachment 85212 [details] demo

Levi Weintraub

Comment 3 2011-03-09 13:56:04 PST

(In reply to comment #2) > Created an attachment (id=85212) [details] > demo I can see where this test case goes wrong, as the position is interpreted as being after the first child of the table element. Can you reproduce this the way the reporter said? Even putting "1" inside a non-content editable span, while it breaks the caret position, doesn't insert or paste content into the wrong location.

Ryosuke Niwa

Comment 4 2011-03-09 14:11:17 PST

(In reply to comment #3) > (In reply to comment #2) > > Created an attachment (id=85212) [details] [details] > > demo > > I can see where this test case goes wrong, as the position is interpreted as being after the first child of the table element. Can you reproduce this the way the reporter said? Even putting "1" inside a non-content editable span, while it breaks the caret position, doesn't insert or paste content into the wrong location. You need to paste HTML. If you just insert plain text, then the content is inserted in the first cell as expected.

Levi Weintraub

Comment 5 2011-03-09 14:16:47 PST

(In reply to comment #4) > You need to paste HTML. If you just insert plain text, then the content is inserted in the first cell as expected. That repros perfectly, thanks :)

cc_lam

Comment 6 2011-09-16 09:38:11 PDT

I can reproduce it in Google Chrome 13.0.782.220 m and in Safari 5.1(7534.50), which are webkit 535.1 and 534.5 respectively.

Sukolsak Sakshuwong

Comment 7 2012-05-24 20:19:47 PDT

Created attachment 143956 [details] Patch

Sukolsak Sakshuwong

Comment 8 2012-05-24 20:30:28 PDT

This bug has been fixed. I added a test to make sure that it won't regress.

WebKit Review Bot

Comment 9 2012-05-24 20:47:18 PDT

Comment on attachment 143956 [details] Patch Attachment 143956 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/12803344 New failing tests: editing/pasteboard/paste-into-table-cell-2.html

WebKit Review Bot

Comment 10 2012-05-24 20:47:23 PDT

Created attachment 143958 [details] Archive of layout-test-results from ec2-cr-linux-04 The attached test failures were seen while running run-webkit-tests on the chromium-ews. Bot: ec2-cr-linux-04 Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'> Platform: Linux-2.6.35-28-virtual-x86_64-with-Ubuntu-10.10-maverick

Sukolsak Sakshuwong

Comment 11 2012-05-25 11:19:27 PDT

Created attachment 144104 [details] Patch

WebKit Review Bot

Comment 12 2012-05-25 14:15:04 PDT

Comment on attachment 144104 [details] Patch Clearing flags on attachment: 144104 Committed r118561: <http://trac.webkit.org/changeset/118561>

WebKit Review Bot

Comment 13 2012-05-25 14:15:09 PDT

All reviewed patches have been landed. Closing bug.

Emerick Rogul

Comment 14 2012-07-31 06:17:24 PDT

Does anyone know the revision number where this bug was fixed, or failing that, the affected source files? This bug item only seems to contain details about the regression test.

Emerick Rogul

Comment 15 2012-07-31 08:26:29 PDT

Nevermind, I found the relevant bug (https://bugs.webkit.org/show_bug.cgi?id=75004).

Note You need to log in before you can comment on or make changes to this bug.