Bug 53933 - Pasting into contenteditable table cell pastes into adjacent cell instead.
Summary: Pasting into contenteditable table cell pastes into adjacent cell instead.
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: HTML Editing (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Nobody
URL:
Keywords: HasReduction
Depends on:
Blocks:
 
Reported: 2011-02-07 12:02 PST by santoscordon
Modified: 2012-07-31 08:26 PDT (History)
10 users (show)

See Also:


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

Note You need to log in before you can comment on or make changes to this bug.
Description santoscordon 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>
Comment 1 Levi Weintraub 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.
Comment 2 Ryosuke Niwa 2011-03-09 12:04:14 PST
Created attachment 85212 [details]
demo
Comment 3 Levi Weintraub 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.
Comment 4 Ryosuke Niwa 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.
Comment 5 Levi Weintraub 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 :)
Comment 6 cc_lam 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.
Comment 7 Sukolsak Sakshuwong 2012-05-24 20:19:47 PDT
Created attachment 143956 [details]
Patch
Comment 8 Sukolsak Sakshuwong 2012-05-24 20:30:28 PDT
This bug has been fixed. I added a test to make sure that it won't regress.
Comment 9 WebKit Review Bot 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
Comment 10 WebKit Review Bot 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
Comment 11 Sukolsak Sakshuwong 2012-05-25 11:19:27 PDT
Created attachment 144104 [details]
Patch
Comment 12 WebKit Review Bot 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>
Comment 13 WebKit Review Bot 2012-05-25 14:15:09 PDT
All reviewed patches have been landed.  Closing bug.
Comment 14 Emerick Rogul 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.
Comment 15 Emerick Rogul 2012-07-31 08:26:29 PDT
Nevermind, I found the relevant bug (https://bugs.webkit.org/show_bug.cgi?id=75004).