Bug 167209

Summary: Safari input elements don't respect line-heights smaller than 'normal'.
Product: WebKit Reporter: Michelle <michelle>
Component: FormsAssignee: zalan <zalan>
Status: RESOLVED FIXED    
Severity: Normal CC: cdumez, changseok, esprehn+autocc, ews-watchlist, glenn, kondapallykalyan, mifenton, mmaxfield, pdr, rmondello, simon.fraser, webkit-bug-importer, wenson_hsieh, zalan
Priority: P2 Keywords: InRadar
Version: Safari 10   
Hardware: Mac   
OS: OS X 10.11   
Bug Depends on: 257462, 257463    
Bug Blocks:    
Attachments:
Description Flags
Fixed centering and sizing
none
overflow content needs clipping (caret does not look ok either)
none
WIP
none
Patch
none
Patch
none
Patch
none
Patch
none
Patch none

Description Michelle 2017-01-19 12:18:13 PST
Here's a minimal reproduction: https://jsfiddle.net/mchl/dxc9geqc/

The placeholder text respects the `0.9em` line-height. However, once you start typing, the input text does not.
Comment 1 zalan 2023-05-26 16:04:47 PDT
This looks like an incorrectly positioned (vertically centered) inner text control (shadow dom)
Comment 2 zalan 2023-05-27 21:25:33 PDT
Sadly RenderTextControlSingleLine does no support cases with layout overflow.
The attached test case sets the height of the input box to 0.9em causing layout overflow. Even if the inner renderer wascentered, since RenderTextControlSingleLine does not support proper clipping, text would simply spill out of the input box (on trunk, placeholder text already overflows :(
it requires
1, centering
2, loosening up on the height cap on the inner renderer (see desiredLogicalHeight in RenderTextControlSingleLine::layout)
3, adding clipping support

(see attached screen recordings)
Comment 3 zalan 2023-05-27 21:26:16 PDT
Created attachment 466519 [details]
Fixed centering and sizing
Comment 4 zalan 2023-05-27 21:27:06 PDT
Created attachment 466520 [details]
overflow content needs clipping (caret does not look ok either)
Comment 5 zalan 2023-05-27 21:28:05 PDT
Created attachment 466521 [details]
WIP
Comment 6 zalan 2023-05-28 22:01:14 PDT
Apparently clipping is reserved for text fields (?) with decorations.

bool RenderTextControlSingleLine::hasControlClip() const
{
    // Apply control clip for text fields with decorations.
    return !!containerElement();
}

will need to do some digging through history.
Comment 7 zalan 2023-05-29 08:11:08 PDT
1. hasControlClip was initially added at 19393@main to specifically clip overflowing magnifier glass/cancel button in search fields ( hasControlClip() const { return m_cancelButton; })

2. 79370@main slightly changed behavior by switching over to checking !!containerElement(). It expands clipping for other, single line text field types like password -anything with container based shadow DOM (not just a simple contenteditable inside input)

which introduced some inconsistencies

<style>
input {
  font-size: 38px;
  height: 20px;
}
</style>
<input type="password" placeholder="this is clipped">
<input type="text" placeholder="this is NOT clipped">
Comment 8 zalan 2023-05-29 15:32:20 PDT
Created attachment 466532 [details]
Patch
Comment 9 zalan 2023-05-31 07:34:41 PDT
Created attachment 466545 [details]
Patch
Comment 10 zalan 2023-05-31 08:13:42 PDT
Created attachment 466548 [details]
Patch
Comment 11 zalan 2023-05-31 19:46:41 PDT
Created attachment 466558 [details]
Patch
Comment 12 zalan 2023-06-01 07:51:54 PDT
Created attachment 466563 [details]
Patch
Comment 13 EWS 2023-06-01 11:49:02 PDT
Committed 264802@main (7590b24a0d02): <https://commits.webkit.org/264802@main>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 466563 [details].
Comment 14 Radar WebKit Bug Importer 2023-06-01 11:50:20 PDT
<rdar://problem/110126574>