Safari 16.0 is ignoring input placeholder line-height and defaulting to normal.
Could you please provide a test case? I'm getting identical rendering from this in Safari, Chrome and Firefox: data:text/html,<input type="text" placeholder="whatever" style="line-height:100px">
You can see the bug live from iOS or macOS Safari 16.0 browsers at revaaa.com in the top search field input. The 'Search RevAAA' placeholder should have a line-height of 1.5 which centres it, but it's actually being displayed as the default normal.
<rdar://problem/100369677>
The bottom of the magnifier icon is hidden too. The input: <input type="search" aria-autocomplete="list" aria-labelledby="downshift-0-label" autocomplete="off" value="" id="search" placeholder="🔍 Search RevAAA" class="" /> The shadow content generated for this input is: <div pseudo="placeholder">🔍 Search RevAAA</div> <div pseudo="-webkit-textfield-decoration-container"> <div pseudo="-webkit-search-decoration"></div> <div><div contenteditable="plaintext-only"></div></div> <div pseudo="-webkit-search-cancel-button" aria-label="cancel" role="button" ></div> <div pseudo="-webkit-list-button" style="display: none !important"></div> </div> The <div pseudo="placeholder">🔍 Search RevAAA</div> has the CSS (defined in the UA stylesheet) input::placeholder { white-space: pre; overflow-wrap: normal; overflow-x: hidden; overflow-y: hidden; line-height: initial; } the sibling div <div pseudo="-webkit-textfield-decoration-container">…</div> has the CSS (also defined in the UA stylesheet) input::-webkit-textfield-decoration-container { display: flex; align-items: center; content: none; } It doesn't seem to be a recent regression at least. Running Autospade autospade -s -O 252432@main:254111@main gave https://commits.webkit.org/compare/253526@main...253496@main Probably regressed by: https://github.com/WebKit/WebKit/commit/0f760ccf1c9e695d6ecf5d6a215a07adc08dcd7f
Note that placeholder line-height is always set to `initial`, as of https://commits.webkit.org/250414@main. This matches other browsers. Following that change, we had to update our logic to vertically center the placeholder (https://commits.webkit.org/253500@main). It looks like that falls apart when using 'font-family: Arial', with an emoji in the placeholder. Reduction: <head> <meta charset="UTF-8"> <style> input { font-family: Arial; } </style> </head> <input placeholder="🔍 Search">
Pull request: https://github.com/WebKit/WebKit/pull/4772
Committed 254962@main (219edafe86a2): <https://commits.webkit.org/254962@main> Reviewed commits have been landed. Closing PR #4772 and removing active labels.
The bug is worse in 16.1
16.1 doesn't have the fix. Please test with Safari Technology Preview 156 or newer.
I've just checked with Release 156 (Safari 16.4, WebKit 17615.1.8.5) in both Monterey and Ventura and the bug remains identical to 16.0 and is not fixed. Please be aware that the placeholder text is being pushed even further down in 16.1. Thank you
Aditya and myself just confirmed that the placeholder on https://revaaa.com is positioned correctly in STP 156 (and it is misplaced in Safari 16.1). Please file a new bug with detailed steps to reproduce if you are still observing an issue. We'll need to investigate it separately.
Created attachment 463276 [details] STP 156 rendering
The positioning is not correct. This is shown in the image you've attached with it not being centred correctly. If you compare this to a version of Safari prior to 16 or Chrome you can see that it's not correct. Also, bear in mind this positioning is identical to the very bug that I reported originally, nothing has changed. Thank you
You can further demonstrate this by using the inspector to remove the search icon from the placeholder text which causes it to shift into the correct centred position.
Created attachment 463278 [details] Safari 16.1 rendering
Created attachment 463279 [details] Safari 16.0 rendering
Positioning in both images is incorrect. 16.1 is just worse.
Fair enough, looks like we saw the Safari 16.1 regression, and fixed that instead. I don't have Safari 15.x to compare to, but it looks slightly different from other browsers. However, please do file a new bug, even though we misused this one to fix something different. If we attempt to track two different fixes in one bug, it will cause further confusion, with a very high chance of the second fix not being included in a release until much later.