Steps: 1) Load document http://blues/users/bijals/publish/composer/composerbor2.htm 2) Go to the table and click in the first column, header row 3) Hit tab Actual Results: Notice that the caret moves to an unusual position in between a table border. Expected Results: Tab moves caret to next cell on the right or to the next row.

reassign to charley for initial triage; cc joe change platform/os to all since I see this on Mac (today's build). Also note that the caret is only wrong for the first tab press, subsequent tab presses in the particular table in the example seem to be fine.

It's not between the table borders. The caret is being moved to the beginning of the cell logically, it happens that the text is in a <center> tag, and the caret is placed at the beginning of the cell, before the <center>. Maybe we should discuss where to put the caret? So the bug is really: why is the caret drawn too high when it is before a center tag in the table? Assinging to Simon for more investigation.

joe or charley should fix this.

Joe: What should we do about this? Do you have or plan to write a method to "put caret in front of deepest first child" for cases like this? Would you like me to write one? Are there other cases when that behavior for placing caret would be good?

Charlie, I am happy for you to do this logic. Just follow the TabInTable() logic, making sure that any code you write for positioning the caret is only called in the TabIntable() case. I can do this if you like, but if you do it then as a bonus you get whatever behavior you want! :-)

Ok, I'll help out -- I know you need some payment for the pain I've caused you because of new list and table selection consequences!

This was fixed, but if you tab into an empty cell, you can't type! Leaving open to investigate that problem

checked in 4/27

verified in 5/16 build.