1895999 - zhuanlan.zhihu.com - Items are misaligned

Status: RESOLVED WORKSFORME

(Web Compatibility :: Site Reports, defect, P3)

Description

[James Graham [:jgraham]]

Environment:
Operating system: Android 14
Firefox version: Firefox Mobile 127.0

Steps to reproduce:
top search bar innertext "搜索" display

Actual Behavior:
Items are misaligned: the items in the top left corner are overlapping the text that should be in the searchbar.

Notes:

• Reproduces regardless of the status of ETP
• Reproduces in Firefox Nightly, Firefox Release
• Does not reproduce in Chrome

Created from https://github.com/webcompat/web-bugs/issues/136267

Comment 1

[Tom25519]

Duplicate of this bug - it even found more issues: https://bugzilla.mozilla.org/show_bug.cgi?id=1893606.

Comment 3

[Thomas Wisniewski [:twisniewski][PTO until Mar.16]]

Attachment: testcase.html

There appear to be two problems here;

1. there is a magnifying glass SVG to the left of the gray search-header text which is not appearing at all (it has no size).
2. the placement of the gray text and SVG is pulled too far to the left on an actual device.

This seems to all be because Firefox handles the placeholder text (or the content area) of the input differently given the combination of flex options and overflow:hidden CSS that the page is using; this is made pretty obvious when viewing the reduced test-case in responsive design mode, and playing with the size of the viewport window.

All is fine when the window is wide enough for everything, but things go awry as it gets narrower. The placeholder text locks into place in Chrome as the input gets too small, whereas in Firefox it is pulled outside of the text element's size. In turn, the SVG shrinks much sooner than it does in Chrome, as the placeholder text seems to push it into oblivion.

Chrome seems to behave similarly to Firefox if I remove the overflow:hidden, so I suspect that's the key to the interop issue here.

Dan, have you seen this kind of thing before?

Comment 4

[Thomas Wisniewski [:twisniewski][PTO until Mar.16]]

There appear to be two problems here;

1. there is a magnifying glass SVG to the left of the gray search-header text which is not appearing at all (it has no size).
2. the placement of the gray text and SVG is pulled too far to the left on an actual device.

This seems to all be because Firefox handles the placeholder text (or the content area of the input line) differently given the combination of flex options and overflow:hidden CSS that the page is using; this is made pretty obvious when viewing the reduced test-case in responsive design mode, and playing with the size of the viewport window. All is fine when the window is wide enough for everything, but things go awry as it gets narrower.

The placeholder text locks into place in Chrome as the input gets too small, whereas in Firefox it is pulled outside of the text element's size. This seems to happen in Chrome as well if overflow:hidden is removed, so I suspect that's the key to any interop issue here.

The SVG vanishes as it's set to shrink, and gets smaller to fix the input box. In Chrome the placeholder text doesn't influence this, but in Firefox the SVG vanishes as if the placeholder text is pushing it into oblivion.

Comment 5

[Daniel Holbert [:dholbert]]

Chrome dev-channel version 128 actually renders the reduced testcase the same way that Firefox does (including at smallish responsive-design-mode sizes), doing the things twisniewski described Firefox doing in comment 4.

Having said that -- Chrome dev-channel does still render the original site nicer than we do. They push the placeholder-text off the left side at a sufficiently-small screen size (e.g. in RDM with "Samsung Galaxy Z fold 5" and "Samsung Galaxy S8", 344px and 360px wide), but they don't have any trouble with a slightly larger screen (e.g. in RDM with "Samsung Galaxy S20 Ultra", 412px wide); whereas Firefox does push the placeholder text pretty far off the left side with "Samsung Galaxy S20 Ultra" as the target device in RDM (412px wide).

Comment 6

[Daniel Holbert [:dholbert]]

So on my linux system at least (where I've been testing in RDM etc), a reduced testcase for the remaining Firefox129-vs-Chrome128-dev-channel is just this (which requires you to have the Noto Sans CJK SC font installed in order to work):

data:text/html,<input style="font-family:Noto Sans CJK SC" value="How wide is this textfield">

For me, Firefox sizes the input element there as 290px wide, whereas Chrome sizes the input element as 156px wide.

This makes a difference in the actual site because they've got an input like that one, which is then horizontally centered in a flex container that's sized to fit a portion of the viewport-width. If the input is wider (as it is in Firefox), it overflows even at larger viewport-sizes (and it overflows off of both sides because it's centered).

Note: on the actual site, the flex container is the thing that draws the border that you visually perceive as the textfield. That's why it looks like the textfield contents are mysteriously leaking outside of the textfield. They're not actually escaping the textfield, but rather the textfield (with no border) is overflowing its parent (which has a border).

Comment 7

[Daniel Holbert [:dholbert]]

Per comment 5, I don't think there's a flexbox rendering difference here vs. latest Chrome prereleases. I've spun off bug 1906016 for the one rendering difference that I am seeing, so let's reclassify this bug here back to WebCompat:SiteReports (it doesn't make sense as a flexbox bug).

Comment 8

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #7)

I've spun off bug 1906016 for the one rendering difference that I am seeing

To clarify, bug 1906016 is focused on the sizing difference when we have an apples-to-apples comparison when everyone is using the "Noto Sans CJK SC" font (or other Noto CJK fonts).

But also: on the actual site here, I think we might be the only browser that's actually finding & using the "Noto Sans CJK SC" system-font, for whatever reason. I filed bug 1906190 on that. That's the proximal reason for our rendering difference on Android, as compared to Chrome-on-Android and Safari-on-iOS; we're the only ones actually using that system-font when it's been requested by the site (which then leads to us exhibiting that font's particular sizing behavior).

Comment 9

[Daniel Holbert [:dholbert]]

The site has changed such that the issue is no longer reproducible.

As noted in comment 0 and in github, the issue here was with some content that spilled out of a searchbar at the top of the page. Nowadays there is no such searchbar.

Comparing the rendering between Firefox and Chrome, the text sizing is slightly different (less so if I turn off font-inflation), but there's nothing obviously broken at this point.
--> WFM