WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
245422
REGRESSION (Safari 16): Input placeholder misplaced on revaaa.com
https://bugs.webkit.org/show_bug.cgi?id=245422
Summary
REGRESSION (Safari 16): Input placeholder misplaced on revaaa.com
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.
Top of Page
Format For Printing
XML
Clone This Bug