Bug 245422

Summary: REGRESSION (Safari 16): Input placeholder misplaced on revaaa.com
Product: WebKit Reporter: Chris <feedback>
Component: FormsAssignee: Aditya Keerthi <akeerthi>
Status: RESOLVED FIXED    
Severity: Normal CC: akeerthi, ap, cdumez, feedback, karlcow, webkit-bug-importer, wenson_hsieh
Priority: P2 Keywords: BrowserCompat, InRadar
Version: Other   
Hardware: Unspecified   
OS: Unspecified   
URL: https://revaaa.com
See Also: https://bugs.webkit.org/show_bug.cgi?id=245225
https://bugs.webkit.org/show_bug.cgi?id=247142
Bug Depends on: 243966    
Bug Blocks:    
Attachments:
Description Flags
STP 156 rendering
none
Safari 16.1 rendering
none
Safari 16.0 rendering none

Chris
Reported 2022-09-20 06:00:59 PDT
Safari 16.0 is ignoring input placeholder line-height and defaulting to normal.
Attachments
STP 156 rendering (123.39 KB, image/png)
2022-10-27 10:17 PDT, Alexey Proskuryakov 		no flags
Details
Safari 16.1 rendering (63.46 KB, image/png)
2022-10-27 10:51 PDT, Alexey Proskuryakov 		no flags
Details
Safari 16.0 rendering (23.42 KB, image/png)
2022-10-27 10:53 PDT, Alexey Proskuryakov 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
Alexey Proskuryakov
Comment 1 2022-09-20 18:35:43 PDT
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">
Chris
Comment 2 2022-09-21 01:09:32 PDT
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.
Radar WebKit Bug Importer
Comment 3 2022-09-24 19:17:56 PDT
<rdar://problem/100369677>
Karl Dubost
Comment 4 2022-09-25 20:38:23 PDT
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
Aditya Keerthi
Comment 5 2022-09-26 10:46:46 PDT
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">
Aditya Keerthi
Comment 6 2022-09-27 15:03:30 PDT
Pull request: https://github.com/WebKit/WebKit/pull/4772
EWS
Comment 7 2022-09-28 09:37:37 PDT
Committed 254962@main (219edafe86a2): <https://commits.webkit.org/254962@main> Reviewed commits have been landed. Closing PR #4772 and removing active labels.
Chris
Comment 8 2022-10-27 01:42:36 PDT
The bug is worse in 16.1
Alexey Proskuryakov
Comment 9 2022-10-27 08:46:46 PDT
16.1 doesn't have the fix. Please test with Safari Technology Preview 156 or newer.
Chris
Comment 10 2022-10-27 09:48:39 PDT
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
Alexey Proskuryakov
Comment 11 2022-10-27 10:17:10 PDT
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.
Alexey Proskuryakov
Comment 12 2022-10-27 10:17:35 PDT
Created attachment 463276 [details] STP 156 rendering
Chris
Comment 13 2022-10-27 10:27:04 PDT
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
Chris
Comment 14 2022-10-27 10:34:25 PDT
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.
Alexey Proskuryakov
Comment 15 2022-10-27 10:51:04 PDT
Created attachment 463278 [details] Safari 16.1 rendering
Alexey Proskuryakov
Comment 16 2022-10-27 10:53:38 PDT
Created attachment 463279 [details] Safari 16.0 rendering
Chris
Comment 17 2022-10-27 10:55:16 PDT
Positioning in both images is incorrect. 16.1 is just worse.
Alexey Proskuryakov
Comment 18 2022-10-27 10:58:46 PDT
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.
Note You need to log in before you can comment on or make changes to this bug.