Bug 70757 – Moving to the start of line should not place the caret outside of the table

• Component: HTML Editing
• Status: RESOLVED FIXED

[Ryosuke Niwa]

When moving to the start of a line (command + left arrow key on Mac; Home on Windows) inside the first table cell, the caret is placed before of the table but this behavior is inconsistent with Firefox, TextEdit, Microsoft Word, which all place the caret in the first position inside the table cell.

[Ojan Vafai]

Do you have a testcase we can play with?

[Ryosuke Niwa]

Created attachment 112247 [details]
test

[Julie Parent]

Does this imply that there is no keyboard navigable way to get out of the table?  What about the reciprocal behavior of moving to the end of the line?

[Ryosuke Niwa]

(In reply to comment #3)
> Does this imply that there is no keyboard navigable way to get out of the table?  What about the reciprocal behavior of moving to the end of the line?

There is. You just need to move using arrow keys without any modifiers, which is what all other browsers and apps do.

Our current behavior is broken and inconsistent. There's no way for users to move to the beginning of a table cell.

Also, moving to the end of a line at the end last table cell doesn't move the caret to a position after the table :( So we're inconsistent with our own behavior.

[Ryosuke Niwa]

One clarification: neither Firefox nor Internet Explorer lets you move the caret before or after the table in the test case I attached. WebKit provides an extra position before/after the table.

[Ojan Vafai]

(In reply to comment #5)
> One clarification: neither Firefox nor Internet Explorer lets you move the caret before or after the table in the test case I attached. WebKit provides an extra position before/after the table.

That's a bug IMO. Firefox/IE should be fixed.

[Ryosuke Niwa]

Created attachment 112366 [details]
fixes the bug

[Chang Shu]

Maybe I missed the previous conversations. I found the following two commits that introduced the function and a fix to that:
http://trac.webkit.org/changeset/25586
http://trac.webkit.org/changeset/63918

Would this code change break the tests in the commits above? Or shall we update their expectations?

[Ryosuke Niwa]

(In reply to comment #8)
> Maybe I missed the previous conversations. I found the following two commits that introduced the function and a fix to that:
> http://trac.webkit.org/changeset/25586
> http://trac.webkit.org/changeset/63918
> 
> Would this code change break the tests in the commits above? Or shall we update their expectations?

All tests still pass.

[Chang Shu]

Comment on attachment 112366 [details]
fixes the bug

The code change matches the new behavior. r=me.

[Ryosuke Niwa]

Thanks for the review.

[WebKit Review Bot]

Comment on attachment 112366 [details]
fixes the bug

Clearing flags on attachment: 112366

Committed r98408: <http://trac.webkit.org/changeset/98408>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.