cbs.com - Small allocated space for "Search" field

[mkaply]

URL: https://cbs.com/search

Browser / Version: Firefox 72.0 Operating System: Windows 10 Tested Another Browser: Yes

Problem type: Design is broken Description: Lowercase g cutoff when window is maximized Steps to Reproduce: Maximize the window. Click the magnifying glass. Start typing a search with lowercase gs. Notice the bottom of the g is cutoff. Screenshot

Browser Configuration

• None

From webcompat.com with ❤️

[mozilla829]

Hi, Thanks for reporting this issue. I was unable to reproduce it, does it occur in a fresh Firefox profile?

[mkaply]

Yes, it does.

How big is your display? This only happens when the search field is made extra large by having the window large.

[mozilla829]

Thanks for getting back to me. My screen is 1366x768, how big is yours?

[softvision-oana-arbuzov]

Thanks for the report @mkaply , I was able to reproduce the issue.

Affected area:

<input type="text" name="q" placeholder="Search shows and movies" autocomplete="off">

Note:

1. Resizing the browser window the search text is fully visible.
2. VPN or USA residence is needed for "Search" field to be active.

Tested with: Browser / Version: Firefox Nightly 74.0a1 (2020-01-27) Operating System: Windows 10 Pro VPN active pointing to USA Screen resolution 1920x1080

Moving to Needsdiagnosis for further investigation.

[karlcow]

@mkaply i can't reproduce on macos with firefox 75 and firefox 71. i wonder which font is loaded.

[mkaply]

On my machine it's definitely using Proxima Nova Light, but I see a slight cutoff if I use sans-serif as well

And I see it on 75 as well. It only happens when the browser window with is over 2180.

[karlcow]

browser window with is over 2180.

👀 🤣 ok that's not often I do that… Though luckily? my screen is 3200. Also I'm not in full screen. But still no luck. :)

Let's ask @jfkthame he will have probably a better answer than mine.

[jfkthame]

Huh, I'm seeing a different issue: for me, the search field is inactive. (It shows "Search shows and movies" faintly in grayed-out text, but is completely unresponsive.) So I can't try entering any text with descenders to see how it looks!

[jfkthame]

Oh, never mind - that's apparently the "onetrust consent sdk" putting a semi-opaque panel over the entire window. If you go to "manage cookies" and leave them disabled, except for the "necessary" ones, then it doesn't remove its blocker element when closing the cookie-management panel.

So much for getting meaningful user consent before forcing all their tracking on me.... :\

Moving along, if I hide the blocker panel using the inspector, then I can indeed type into the search field. I'm not seeing any clipping problem here on macOS; I'll take a look on Windows when I have that system running.

[jfkthame]

So there are a couple of things going on here.

First, the reason we see a problem on Windows, but not on other platforms, is related to the font they're using (Proxima Nova). Inspecting the OS/2 table in the font, I find (excerpt):

<fsSelection value="00000000 01000000"/>
<usFirstCharIndex value="0"/>
<usLastCharIndex value="64259"/>
<sTypoAscender value="775"/>
<sTypoDescender value="-225"/>
<sTypoLineGap value="383"/>
<usWinAscent value="1116"/>
<usWinDescent value="267"/>

Note the large usWinAscent value here. Because bit 7 of fsSelection (defined in the OpenType spec as USE_TYPO_METRICS is not set, this causes the DirectWrite GetMetrics API that we use to return a large ascent value for the font, which has the effect of forcing the baseline of the text much lower on Windows than on other platforms (where usWinAscent is not used).

If the font had the USE_TYPO_METRICS bit set in fsSelection (and the OS/2 table upgraded to version 4 from the current v3, where this bit was not defined), then DirectWrite would use the sTypo* metrics like other platforms, and we'd get more consistent positioning of the text within its line height.

The other thing that seems to be relevant, and the reason Chrome (for example) doesn't have the same problem -- even though the lack of USE_TYPO_METRICS does have an effect on its baseline placement -- is how the height of the <input> element is computed. When the window is very wide, we have line-height: 60px and font-size: 60px applied to it, and in Firefox this results in the <input> element itself also having height = 60px, which (given the low text baseline that results from the use of usWinAscent as described above) leads to the descenders being clipped.

In Chrome, on the other hand, although the <input> element has font-size: 60px and line-height: 60px applied, it ends up with a computed height of 83px, and so there's enough room for the large characters.

So the question then is how the (auto) height of an <input> is derived from its font-size and line-height; we don't seem to have interop here. I'm not sure offhand if this is fully spec'd anywhere...

As for immediate fixes that could be applied by the site: fixing the font to have the USE_TYPO_METRICS bit set would probably help. Or setting a more realistic line-height on the <input> element when its font-size is increased (currently, the line-height is 60px when the window is narrower, such that the font-size is 38px, and it is not increased when they bump the font-size to 60px for a wide window). Setting something like line-height: 1.5em would probably help a lot.

[jfkthame]

Just to follow up here, I believe Gecko's behavior is actually more conformant to the current text of the HTML spec, but the WebKit/Blink behavior is more sensible and is what sites like this are relying on. So I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1623124 to make Gecko's behavior more similar to the other browsers, and https://github.com/whatwg/html/issues/5366 about updating the spec to match this reality.

Here's hoping this will result in better interop in this area, and fewer broken sites!

[karlcow]

Duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=1623124 (Thanks a lot for the beautiful explanation)

[lock[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue at https://webcompat.com/issues/new if you are experiencing a similar problem.