Currently, caret's height is current line's height, but it looks weird for editable contents with an image and text on the same line (Or text with variable font-sizes). For example, from the attached editable.htm, you can see the caret height is too big while editing the text. When I checked the Firefox and the MS Word, the caret height was not a line's height, but a current object's height, and it looks more reasonable.
Created attachment 202251 [details] test case
Created attachment 202252 [details] Patch
Comment on attachment 202252 [details] Patch Attachment 202252 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://webkit-queues.appspot.com/results/447106 New failing tests: editing/selection/caret-alignment-for-vertical-text.html
Created attachment 202263 [details] Archive of layout-test-results from webkit-ews-15 for mac-mountainlion-wk2 The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews. Bot: webkit-ews-15 Port: mac-mountainlion-wk2 Platform: Mac OS X 10.8.3
Comment on attachment 202252 [details] Patch I am not sure this is right for Mac user interface, even though it might be OK on other platforms.
Comment on attachment 202252 [details] Patch Definitely not right for Mac.
(In reply to comment #6) > (From update of attachment 202252 [details]) > Definitely not right for Mac. Do you mean current operation is right for Mac port? On attached test case, caret height became 1171px, and when window height is smaller than that, you can't see the text while editing because the contents is scrolled up to the top - it's same on the Safari. Is it OK for Mac port?
(In reply to comment #7) > Do you mean current operation is right for Mac port? Caret being as tall as the tallest image on a line is the correct behavior for the Mac port. You can see it in OS X applications such as TexTEdit. > On attached test case, caret height became 1171px, > and when window height is smaller than that, > you can't see the text while editing because the contents is scrolled up to the top - it's same on the Safari. > Is it OK for Mac port? There may be a problem there that needs to be solved, but it is not right to solve it by making the caret ignore the heights of images that are on the same lines as text. The user interface design for Mac means that the caret is supposed to be based on the line height, which can be affected by images as well as text on that line. We’ll have to think of some other solution. Possibly, we can fix the issue that you can’t see the text when editing by changing the rules for scrolling. And we might invent some different UI for when the images are so tall that the caret as tall as the tallest image on a line is silly or absurd. But just changing the rule to “caret heights consider only text ignoring images” is wrong for Mac UI.
Created attachment 202497 [details] Patch
Did you run all layout tests? I'll be surprised if this change doesn't cause any test failure.
Comment on attachment 202497 [details] Patch This patch needs to rebaseline all the editing tests' pixel results. We should probably make this dependent on the editing behavior instead.
*** This bug has been marked as a duplicate of bug 249621 ***