Bug 116424 – Caret height is wrong for editable contents

• Component: HTML Editing
• Status: RESOLVED DUPLICATE

[KyungTae Kim]

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.

[KyungTae Kim]

Created attachment 202251 [details]
test case

[KyungTae Kim]

Created attachment 202252 [details]
Patch

[Build Bot]

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

[Build Bot]

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

[Darin Adler]

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.

[Ryosuke Niwa]

Comment on attachment 202252 [details]
Patch

Definitely not right for Mac.

[KyungTae Kim]

(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?

[Darin Adler]

(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.

[KyungTae Kim]

Created attachment 202497 [details]
Patch

[Ryosuke Niwa]

Did you run all layout tests?  I'll be surprised if this change doesn't cause any test failure.

[Ryosuke Niwa]

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.

[Joone Hur]

*** This bug has been marked as a duplicate of bug 249621 ***