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.
Do you have a testcase we can play with?
Created attachment 112247 [details] test
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?
(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.
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.
(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.
Created attachment 112366 [details] fixes the bug
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?
(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.
Comment on attachment 112366 [details] fixes the bug The code change matches the new behavior. r=me.
Thanks for the review.
Comment on attachment 112366 [details] fixes the bug Clearing flags on attachment: 112366 Committed r98408: <http://trac.webkit.org/changeset/98408>
All reviewed patches have been landed. Closing bug.