Bug 210622 - Oversized caret and selection rects in text fields on ganji.com and netflix.com/login
Summary: Oversized caret and selection rects in text fields on ganji.com and netflix.c...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: HTML Editing (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Wenson Hsieh
URL:
Keywords: InRadar
: 126193 (view as bug list)
Depends on:
Blocks:
 
Reported: 2020-04-16 15:23 PDT by Wenson Hsieh
Modified: 2022-06-01 08:28 PDT (History)
15 users (show)

See Also:

Attachments
Not for review (4.32 KB, patch)
2020-04-16 15:28 PDT, Wenson Hsieh 		no flags Details | Formatted Diff | Diff
Fixes the bug (31.26 KB, patch)
2020-04-18 00:29 PDT, Wenson Hsieh 		no flags Details | Formatted Diff | Diff
Minimal repro case (33 bytes, text/html)
2020-04-18 07:48 PDT, Wenson Hsieh 		no flags Details
More rebaselining (36.15 KB, patch)
2020-04-18 08:17 PDT, Wenson Hsieh 		no flags Details | Formatted Diff | Diff
Show Obsolete (2) View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Wenson Hsieh 2020-04-16 15:23:36 PDT 
<rdar://problem/45945636>
Comment 1 Wenson Hsieh 2020-04-16 15:28:49 PDT Comment hidden (obsolete)
Comment 2 Wenson Hsieh 2020-04-18 00:29:26 PDT Comment hidden (obsolete)
Comment 3 zalan 2020-04-18 06:52:43 PDT 
Could you attach a simple test case, please (I can't tell from the test case which div is behaving correctly and which one is not)? I'd like to debug this a bit.
Comment 4 Wenson Hsieh 2020-04-18 07:47:25 PDT 
(In reply to zalan from comment #3)
> Could you attach a simple test case, please (I can't tell from the test case
> which div is behaving correctly and which one is not)? I'd like to debug
> this a bit.

Sure! There’s not much to the minimal repro case; it’s just an editable root with a line height larger than the font size.

E.g., data:text/html,<input style="line-height: 10em">

Both when the field is initially focused and when it has text, the caret height should be about the same as the font size. Currently, it is not (the height when the field is empty is the height of the field, and then it changes to be come ≈ font height + (line height / 2) once text is entered.

In my test case, all text fields except for id="vertical” exhibit the undesired behavior.
Comment 5 Wenson Hsieh 2020-04-18 07:48:52 PDT 
Created attachment 396847 [details]
Minimal repro case
Comment 6 zalan 2020-04-18 07:51:36 PDT 
It looks like the caret is not sitting on the baseline (initially).
Comment 7 Wenson Hsieh 2020-04-18 08:17:51 PDT 
Created attachment 396850 [details]
More rebaselining
Comment 8 Wenson Hsieh 2020-04-18 08:18:59 PDT 
(In reply to zalan from comment #6)
> It looks like the caret is not sitting on the baseline (initially).

If it helps at all, we go through a different codepath (RenderBoxModelObject::localCaretRectForEmptyElement) when computing the caret rect in this case.
Comment 9 Wenson Hsieh 2020-04-20 08:44:07 PDT 
Comment on attachment 396850 [details]
More rebaselining

Thanks for the review!
Comment 10 EWS 2020-04-20 08:53:53 PDT 
Committed r260367: <https://trac.webkit.org/changeset/260367>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 396850 [details].
Comment 11 zalan 2022-06-01 08:28:45 PDT 
*** Bug 126193 has been marked as a duplicate of this bug. ***