Bug 187413 – WebKit is inconsistent on baseline alignment of elements with non-default "overflow" value (depending on whether scrollbars are present)

• Status: RESOLVED
• Resolution: CONFIGURATION CHANGED
• Component: Layout and Rendering

[Daniel Holbert]

Created attachment 344456 [details]
testcase 1

STR:
 1. Load attached testcase.
 2. Look at the positioning of the "abc" text.

ACTUAL RESULTS:
In the top "short content" case, abc is baseline-aligned with the text inside the black box.
In the bottom "tall content" case, abc is basleine-aligned with the border-bottom of the black box.

EXPECTED RESULTS:
These cases should behave the same.
Interoperability (and perhaps some spec text) suggest that the latter behavior (using the border-bottom for baseline alignment) is the correct behavior -- that's what Firefox, Chrome, and Edge do here.


NOTE: the two cases in this testcase are *identical*, aside from the fact that there's some taller content in the lower one.  Both of them involve an "overflow:auto;display:inline-block" element, which we're trying to baseline-align with some "abc" text.

I'm testing with Safari 11.1 on Mac OS High Sierra.

[Daniel Holbert]

Created attachment 344457 [details]
screenshot of testcase, showing bug (abc inconsistently baseline-aligned with black box)

[Ahmad Saleem]

I am not able to reproduce the incorrect behavior based on reference screenshot using attached test case in Safari 16.3, STP166 and WebKit ToT.

Safari is matching Chrome Canary 113 and Firefox Nightly 113. Marking this as “RESOLVED CONFIGURATION CHANGED”. Thanks!