Open Bug 1626855 Opened 4 years ago Updated 1 year ago

Bottom menu-options from Henan government website are not contained in the hover-selector

Categories

(Core :: Layout: Form Controls, defect, P3)

67 Branch
Unspecified
macOS
defect

Tracking

()

REOPENED
mozilla77
Tracking Status
firefox-esr68 --- wontfix
firefox74 --- wontfix
firefox75 --- wontfix
firefox76 --- wontfix
firefox77 --- fixed

People

(Reporter: cfogel, Assigned: jfkthame)

References

(Depends on 1 open bug, Regression, )

Details

(Keywords: regression)

Attachments

(5 files)

Affected versions

  • 75.0, 76.0a1 (2020-04-01)

Affected platforms

  • macOS 10.15.3;

Steps to reproduce

  1. Launch Firefox, access https://www.henan.gov.cn/
  2. Scroll all the way down;
  3. Click on any dropdown button from the bottom of the page;
  4. Hover around over the listed options;

Expected result

  • font-text is contained in the hover-selector;

Actual result

  • top-side of font-text is not contained;
  • selector styling not properly applied

Regression range

  • First bad: 2019-02-28
  • Last good: 2019-02-27
  • Pushlog: URL;

Additional notes

  • attached recording with the issue.
Has Regression Range: --- → yes
Has STR: --- → yes

text issue or form layout?

Component: Internationalization → Layout: Text and Fonts

This doesn't seem to reproduce for me, it looks fine here; see attached screenshot. Possibly dependent on locale settings (of the browser and/or OS installation), or on font preferences?

I was able to reproduce this on my macOS machine. I ran it through mozregression and narrowed it down to the following dates:

 6:49.13 INFO: Last good revision: 198cd4a81bf2afa7cc79360f90da7bc91218b76d (2019-02-27)
 6:49.13 INFO: First bad revision: 98d4803bb2de7fcdb0096ddeedaefd29d0fd5fd4 (2019-02-28)

Here is the corresponding push log:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=198cd4a81bf2afa7cc79360f90da7bc91218b76d&tochange=98d4803bb2de7fcdb0096ddeedaefd29d0fd5fd4

Nothing in the push log is catching my eye as to what may have introduced this behavior.

I'm going to mark this as P3 due to the fact that this does not seem to be a recent regression.

Jonathan, you said that you didn't see this behavior. Can you try running these dates in mozregression and see if there is a difference for you?

mozregression --launch 2019-02-27
mozregression --launch 2019-02-28
Flags: needinfo?(jfkthame)
Priority: -- → P3

At least comment 0 and comment 3 have the same regression range, although I'm surprised that mozregression (on mac?) doesn't bisect autoland / mozilla-inbound.

That said, I suspect the most likely regressing change is this one.

It might be useful to know what font is selected when people see the bug.

Regressed by: 1375476

OK, I see why the issue didn't reproduce for me: it was affected by additional CJK fonts that I have installed locally. After disabling my extra fonts, the popup is now rendered with PingFang SC (from preferences: font.name-list.sans-serif.zh-CN), and I see the same issue as shown in the original report.

The site just specifies font-family: "微软雅黑"; on the body element, without offering other fallbacks or generics, which suggests to me they've only really looked at Windows when designing this, and everyone else will see whatever defaults their browser happens to offer. Still, we should try to see how this can be improved.

Flags: needinfo?(jfkthame)

So this seems to be a result of a combination of factors:

  • the site uses font-family: inherit on the <select> and <option> elements, which overrides the defaults we would otherwise get for the widgets
  • the font-family list that it has specified, which is being inherited here, lists only a Windows Chinese font, so for non-Windows users it is effectively an empty font-family list, and we'll fall back to a default generic
  • on macOS, the Chinese font prefs include a Latin face first in the list, e.g. pref("font.name-list.sans-serif.zh-CN", "Helvetica, PingFang SC, STHeiti, Heiti SC"); (this is deliberately done so that Latin characters occurring within Chinese-tagged content will be drawn from the Latin font, which users prefer over the Latin glyphs provided in many CJK faces)
  • on macOS, the font metrics we get for Helvetica give quite a "tight" ascent, which doesn't suit the CJK glyphs in PingFang (or other fonts) very well
  • the <option>s here end up with their heights/baselines being computed based on Helvetica metrics, because Helvetica is the first available font in the font-family list they're inheriting (given that the actual font named by the site isn't available, and Helvetica is first in the fallback prefs)

The issue can be seen with an example like

data:text/html;charset=utf-8,<span style="background:rgba(99,99,0,.5);font: 16px helvetica">helvetica 你好

where (assuming default macOS fonts), the Chinese glyphs can be seen to project slightly above the background of the <span>.

Comparing

data:text/html;charset=utf-8,<span style="background:rgba(99,99,0,.5);font: 16px arial">arial 你好

we see that the ascent/descent metrics of Arial are such that the baseline ends up a bit lower within the <span> (or equivalently, the shaded background, which extends from ascent to descent, appears higher relative to the text), and the Chinese glyphs fit more comfortably within it.

Given this, I think perhaps we should update the Chinese font prefs on macOS to use Arial as their associated (prefixed) Latin font, rather than Helvetica. This will serve the same purpose of providing a "standard" font for Latin characters that occur within Chinese content, but will result in line metrics that are better suited to the actual Chinese characters.

BTW, there's a similar issue with the default serif font prefs, in that the macOS "Times" font gives us metrics similar to Helvetica, which don't fit CJK glyphs very well; we'll get a better result using "Times New Roman" instead.

Pushed this to tryserver: https://treeherder.mozilla.org/#/jobs?repo=try&revision=f18b33f21f4bc726b1b37d1db9aa64d77477de90. Not marking for review just yet, as I suspect it'll probably disrupt a bunch of tests and we'll need to update them appropriately.

Well, that went surprisingly smoothly -- I guess tests aren't as fragile as I was expecting!

Assignee: nobody → jfkthame
Status: NEW → ASSIGNED

We probably don't have many tests language-tagged as Chinese...

True, but I still anticipated some minor breakage might show up.

Just out of curiosity, as an approximation:

$ egrep -r 'lang="?zh' layout/reftests/ | wc -l
      66
$ egrep -r 'lang="?zh' testing/web-platform/tests/ | wc -l
     116
Pushed by jkew@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/1e6168d86a06
Specify Arial & Times New Roman rather than Times & Helvetica as Latin faces in the macOS Chinese font prefs, for better line height metrics. r=m_kato
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla77

Hmm, I can still notice the issue on the reported website with 77.0a1 (2020-04-15) even after turning off any additional font enabled via FontBase.

Attached is a video with the fonts enabled on this device, is there a chance any of them might still mess with it?

Flags: needinfo?(jfkthame)

(In reply to Cristian Fogel, QA [:cfogel] from comment #15)

Created attachment 9140936 [details]
Screen Recording 0002-04-16 at 08.31.19.mov

Hmm, I can still notice the issue on the reported website with 77.0a1 (2020-04-15) even after turning off any additional font enabled via FontBase.

Attached is a video with the fonts enabled on this device, is there a chance any of them might still mess with it?

I don't know why this would be; maybe you could attach a new screenshot showing the issue, so we can try to determine what font is being used, if it's not the same as I see on my macOS machine.

Flags: needinfo?(jfkthame)

Attached an image with the ones used in-browser.
Ignore the shape of the menu in page / scaled so the inspector can display all the used fonts.

Hmm, curious... you're getting Hiragino (a Japanese font) as well as PingFang (Chinese), whereas I get only the Chinese font. This may be related to system and/or browser language preferences, as the page fails to declare a lang attribute of any kind, afaics.

But anyhow, I am also seeing the problem again now, although I thought it was better before. Not sure what may have changed (maybe something about how I was testing locally?), but we should take another look at this and try to figure out a more complete solution.

(Moving this to Form Controls as that seems a better fit for the issue.)

Status: RESOLVED → REOPENED
Component: Layout: Text and Fonts → Layout: Form Controls
Resolution: FIXED → ---
Depends on: 1649059
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.