Bug 32622 – Right clicking in a table cell creates a selection that extends into the next cell

• Component: HTML Editing
• Status: RESOLVED FIXED

[Enrica Casucci]

Created attachment 44998 [details]
Repro case

Repro Steps --
1. Create an application with a WebView.

2. Create and open an HTML file with the following element:
<table border="1" cellspacing="0"><tr><td width="50" height="25pt"></td><td width="50" height="25pt"></td><td width="50" height="25pt"></td></tr></table>

3. Make sure there is nothing selected (other than a typing cursor).

4. Right-click inside the first table cell.

5. Call [WebView selectedDOMRange] and look at the result.

Expected: A DOMRange with the table cell we clicked on as the start/end containers.

Instead: The table cell is only the start container, and the end container is the next table cell over.
---

Description --
***
When there is a table with empty table cells and you right-click inside of an empty table cell, [WebView selectedDOMRange] returns a DOMRange that has the table cell as the start container, but the end container is the next table cell. If the table cell you right-click on is the last cell in the table row, then the end container is the first table cell on the next table row.

This means that there is no way to distinguish between:
1. Right clicking on a single table cell (in which case the entire cell is selected automatically)
2. Selecting a table cell plus the cell next to it, then right clicking.
***
Currently, selecting two adjacent cells gives a DOMRange that is identical to the selection that results from right-clicking on the first of the two cells.

[Enrica Casucci]

Created attachment 44999 [details]
Patch

[WebKit Review Bot]

style-queue ran check-webkit-style on attachment 44999 [details] without any errors.

[Eric Seidel (no email)]

Comment on attachment 44999 [details]
Patch

It seems this should probably be a dumpAsText() test given that all we care about is verifying that the final selection is correct.

Otherwise this looks fine.

[Enrica Casucci]

(In reply to comment #3)
> (From update of attachment 44999 [details])
> It seems this should probably be a dumpAsText() test given that all we care
> about is verifying that the final selection is correct.
> 
> Otherwise this looks fine.

I tried the dumpAsText, but the output is empty. I'll stick to dumpEditingCallbacks. Thanks!

[Enrica Casucci]

Committed revision 52220.