Closed Bug 1704404 Opened 4 years ago Closed 4 years ago

Excessive tab height when displaying page titles including Unicode math symbols

Categories

(Firefox :: Tabbed Browser, defect, P2)

Product:
Firefox
Component:
Tabbed Browser
Version:
Firefox 89
Platform:
Desktop
Linux
Type:
defect
Points:
1

Tracking

()

Status:
VERIFIED FIXED
Milestone:
92 Branch
Tracking Flags:
Tracking Status
relnote-firefox --- 91+
firefox-esr78 --- unaffected
firefox-esr91 91+ verified
firefox90 --- wontfix
firefox91 --- verified
firefox92 --- verified
firefox93 --- verified

People

(Reporter: joaquim.monteiro, Assigned: jfkthame)

References

(Blocks 1 open bug)

Details

(Whiteboard: [proton-tabs-bar] [priority:2c])

Attachments

(6 files)

Screenshot of the bug
166.23 KB, image/png
Details
Bug in the address bar suggestions
13.04 KB, image/png
Details
tc.html
104 bytes, text/html;charset=utf-8
Details
Mozregression Log
21.13 KB, text/plain
Details
fc-list
100.42 KB, text/plain
Details
Bug 1704404 - Apply an explicit line-height to tab labels, in case the title uses fallback fonts with excessive ascent/descent metrics. r?jaws
48 bytes, text/x-phabricator-request
jcristau
: approval-mozilla-release+
jcristau
: approval-mozilla-esr91+
Details | Review
Attached image Screenshot of the bug —

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:89.0) Gecko/20100101 Firefox/89.0

Steps to reproduce:

Opened a web page composed of the following HTML code (the title was originally found in a YouTube video):

<html>
<head>
<title>𝗧𝗛𝗘 𝗜𝗡𝗖𝗜𝗗𝗘𝗡𝗧 - YouTube</title>
</head>
</html>

Note: I tested it on a clean profile, and it still happens.

Actual results:

The tab bar became much taller than required to show the title. (see attached screenshot)

Expected results:

The tab bar staying the same size, as no additional height is required to display the title.

Component: Untriaged → Tabbed Browser
Hardware: Unspecified → Desktop

If you're as confused as me, those are UNICODE math symbols
https://www.utf8-chartable.de/unicode-utf8-table.pl?start=120276&number=128

Which version of Firefox (date) and OS are you using (from about:support)? I can't reproduce it on macOS 20210410214333.

(In reply to Francesco Lodolo [:flod] from comment #1)

Which version of Firefox (date) and OS are you using (from about:support)? I can't reproduce it on macOS 20210410214333.

This is the 2021-04-11 nightly (build ID 20210411093417). It didn't appear in this version though, earlier nightlies had the same issue.
about:config reports my OS as "Linux 5.11.12-zen1-1-zen #1 ZEN SMP PREEMPT Wed, 07 Apr 2021 21:48:33 +0000". I can add that it's Arch Linux with the Sway window manager (I'm using Wayland).
It's possible that it's a font issue, I have Noto Sans as the default font.

Just tested under KDE instead of Sway, same thing. Also, it seems to also happen when the page is suggested in the address bar (see screenshot).

(In reply to Joaquim Monteiro from comment #2)

It's possible that it's a font issue, I have Noto Sans as the default font.

What happens if you change it?

(In reply to Francesco Lodolo [:flod] from comment #5)

(In reply to Joaquim Monteiro from comment #2)

It's possible that it's a font issue, I have Noto Sans as the default font.

What happens if you change it?

Changing it to DejaVu Sans fixes the issue. I also tried Droid Sans, and the issue still occurs with it.

I've also noticed that if, with Firefox closed, I open the page directly (by double-clicking on the file), the issue does not occur until I refresh the page or open it in another tab by double-clicking it again.

Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: [proton-tabs-bar]
Priority: -- → P2
Whiteboard: [proton-tabs-bar] → [proton-tabs-bar] [priority:2c]

(In reply to Joaquim Monteiro from comment #6)

I've also noticed that if, with Firefox closed, I open the page directly (by double-clicking on the file), the issue does not occur until I refresh the page or open it in another tab by double-clicking it again.

This sounds pretty wonky. Jonathan, do you have any inkling of how this would happen? I assume it's something to do with font metrics but I don't know what else is involved here.

Flags: needinfo?(jfkthame)

The text there is not using normal Latin-script letters, it's using characters from the Mathematical Sans-serif Bold block in Unicode's supplementary plane (around U+1D5xx). As such, the characters aren't supported by most normal text fonts, they're generally only found in specialized fonts designed for mathematical typography. So when they occur in the title, Firefox can't draw them using the normal user interface font; instead, fallback comes into play and it searches for some other font that actually supports these characters.

Math symbol fonts, though, often have much larger line metrics than regular text fonts, to allow for the wide range of symbols of various sizes that may occur. And so if the element is using auto sizing rather than an explicitly fixed height, it may grow much larger than expected. (And if the height were fixed, it's possible the baseline of the text would be pushed much too low because of the large metrics of the math font.)

Changing the default font to DejaVu Sans presumably fixed the problem because DejaVu (unlike most text fonts) does support a bunch of these supplementary math characters, and so fallback didn't need to happen.

I'm guessing that the odd situation where the issue didn't occur on initial display but appeared later probably relates to asynchronous font fallback, where at the time the initial reflow happened, we hadn't yet figured out what font we could use for this text, and so the element got sized based on the default font; but once enough font data has been loaded to actually handle these characters, we use the associated metrics and you get the taller element.

Flags: needinfo?(jfkthame)
Summary: Tab bar becomes unreasonably tall when displaying certain page titles → Excessive tab height when displaying page titles including Unicode math symbols
See Also: → 1704055

I just tried it with a video with only ascii characters, it still happens. I use "System San Francisco" as my system font, I'll try changing to something more common to see if the issue persists.
I use Firefox Developer Edition under Arch Linux with i3 window manager

Attached file tc.html —

I have attached the test case in comment 0 for easier investigation on different systems.

I have attempted reproducing this issue, but I was unsuccessful. I have attempted reproducing in Ubuntu 20 with i3, Ubuntu 20 with Sway, Fedora 33 with Wayland on all the latest versions of the main channels. I also attempted changing the system font as discussed in the other bug, but I was still unsuccessful. (I have to mention that I don't know how to change the system font on i3 and sway window managers, only on stock ubuntu 20)

I have to mention that I do not know what I am missing from reproducing it.
Can you provide me with the correct way to change system fonts in any Linux distributions?
Do you have any idea what I could be missing from my configuration?

Thank you!

Flags: needinfo?(joaquim.monteiro)

(In reply to Bodea Daniel [:danibodea] from comment #17)

I have attempted reproducing this issue, but I was unsuccessful. I have attempted reproducing in Ubuntu 20 with i3, Ubuntu 20 with Sway, Fedora 33 with Wayland on all the latest versions of the main channels. I also attempted changing the system font as discussed in the other bug, but I was still unsuccessful. (I have to mention that I don't know how to change the system font on i3 and sway window managers, only on stock ubuntu 20)

I have to mention that I do not know what I am missing from reproducing it.
Can you provide me with the correct way to change system fonts in any Linux distributions?
Do you have any idea what I could be missing from my configuration?

Thank you!

The proper way is to edit the ~/.config/gtk-3.0/settings.ini file, changing the gtk-font-name to the font you want to test. If the font settings aren't applied (or if you want to change fonts temporarily), use gsettings to do so, by running gsettings set org.gnome.desktop.interface font-name "Droid Sans Regular 10", for example.

Flags: needinfo?(joaquim.monteiro)

As a "me too", I've been seeing this on Arch Linux using GNOME with the default fonts (Cantarell Regular 11 for "interface text" and Cantarell Bold 11 for "legacy window titles" and DejaVu Sans Serif 16 in Firefox). I have a huge number of tabs in my session and I don't know if or whether one of them causes this. It shows up like this right from the start most of the time, but not always. For what it's worth, I'm also using Auto Tab Suspend, which adds a 💤 character before the title of the suspended tabs.

I'm affected by this bug on Arch Linux with KDE (Firefox 89.0).
Using DejaVu Sans as my system and Firefox font.
Testcases are either of these two youtube videos:
https://www.youtube.com/watch?v=JUoqpLnjB74
https://www.youtube.com/watch?v=wg3ZXFthmg8

Same issue here, on Firefox 89.0 with DejaVu Sans Serif 16. I first came across the bug on this page: https://twitter.com/AvisPhotoshops/status/1400513072628895746.

Three comments above I wasn't sure why it only happened sometimes, but I realized that toggling between the maximized and restored states reproduces the issue.

And I think it's a regression, but I don't see a bisection here.

Same thing here. https://developer.elementary.io/ triggers the same behavior to me.

Some additional info:

  • I can reproduce it with Unicode U+2A00 character ⨀
  • I resolved by change my font form "Inter Regular" to "Sans Regular" in /gnome tweaks/interface text
See Also: → 1716661
See Also: → 1714276, 1712663
Attachment #9223559 - Attachment mime type: text/html → text/html;charset=utf-8
Attached file Mozregression Log —
mozregression (the GUI binary segfaults for me btw) suggests that it's a regression on nightly between 2021-06-13 and 2021-06-14, which doesn't really make sense since this was reported 3 months ago. Is there some other infrastructure/dependency change around that time that can trigger the issue?. Here's the full mozregression log.

Other than the fact that the date doesn't match up, at least the two commits identified by bisect are both fonts related....

I assume those just changed what font are used in the tab title. Is there a way for me to figure out which font is actually used there and force that during the bisect process?

Bug 1714762 made it more likely that Noto Sans Symbols will be used as a fallback for characters that aren't present in the main font being used; that font has a larger-than-typical height (in order to accommodate some symbols that are particularly tall and/or deep, presumably), and that'll be what is affecting the tab height.

I'm surprised the tabs haven't been given an explicitly-specified height, though. Leaving them to auto-size themselves to their content seems like it will always carry the risk of odd discrepancies happening, depending on the particular fonts that happen to be available and the characters that occur in the page titles.

(In reply to Jonathan Kew (:jfkthame) from comment #35)

I'm surprised the tabs haven't been given an explicitly-specified height, though.

The font-size is not known ahead of time, nor is the font family (both come from the OS preferences), so the line height in px is not known, so doing this is... not straightforward. Do you have suggestions for how such a height should be determined?

Flags: needinfo?(jfkthame)

Presumably the height could be specified in em units, so that it would adapt itself to the font size being used (but would be independent of the metrics of any fallbacks that might happen to get used for "weird" characters).

Flags: needinfo?(jfkthame)

(I'm assuming that in the unlikely event that a page title really does contain exceptionally tall/deep characters, it's better from a design-stability point of view to let it be clipped than to arbitrarily let the tab grow to accommodate it.)

By the way, this also happens for the urlbar dropdown list and tab tooltips.

The character for me is 𝑽 and rendered font is Latin Modern Math but the OS actually prefers DejaVu Math TeX Gyre or DejaVu Serif. In web content it uses DejaVu Serif so it's fine.

Can reproduce on this YT link using 89.0.2 (64-bit) Firefox for Arch Linux. It has "𝘀𝘁𝗶𝗺𝘂𝗹𝗮𝘁𝗲 𝘆𝗼𝘂𝗿 𝘀𝗲𝗻𝘀𝗲𝘀" in the title

(In reply to lilydjwg from comment #42)

By the way, this also happens for the urlbar dropdown list and tab tooltips.

Please file a separate bug for this. Any fix we apply here is unlikely to affect the URL bar dropdown and/or tooltips.

Flags: needinfo?(lilydjwg)

(In reply to :Gijs (he/him) from comment #44)

Please file a separate bug for this. Any fix we apply here is unlikely to affect the URL bar dropdown and/or tooltips.

Done as bug 1719436.

Flags: needinfo?(lilydjwg)

Adding the following to userChrome.css serves as a workaround until this is fixed:

.tab-label {
  line-height: 1em;
}
OS: Unspecified → Linux
See Also: → 1671525

I tried to reproduce this on Ubuntu 19.10 with the Droid Sans font installed from https://www.fontsquirrel.com/fonts/droid-sans, creating a settings.ini file per comment 18 and restarting my system but I couldn't reproduce any odd tab shape sizes.

Did I install the wrong font? I couldn't reproduce it before installing the font either.

I expect comment 46 to be close to what we want, maybe: line-height: 1.2em; max-height: 1.2em; overflow: clip; but without testing it I can't confirm. We will also want to make sure that the overall tab height is unchanged from the current design.

Do you have Latin Modern Math installed? If not, you may need to add it -- I think that's what font fallback is finding in the problem cases. (The relevance of the font chosen in the gtk settings is that it should not include the Unicode math symbols, so that font fallback comes into play.)

:jaws, according to discussion in bug 1719953 it sounds like reproducing this may be dependent on having an older version (v1.958) of Latin Modern Math installed.

This is available directly from the font developers at http://www.gust.org.pl/projects/e-foundry/lm-math/download/latinmodern-math-1958.zip. Only the newer v1.959 is listed on the downloads page, but it turns out the older .zip is still present on the server.

Flags: needinfo?(jaws)
Attached file fc-list —
I don't seem to have such a font installed. Here's my `fc-list`: ```

I don't seem to have such a font installed. Here's my fc-list:

It looks like you have a bunch of LatinModernMath-related fonts that are part of the MathJax package; I suspect one or more of these is probably involved in the issue here.

Those are provided by mathjax2 - 2.7.9.

I can provide a full list of all my system packages and their versions if that helps reproduction. Honestly, if there's any app to automate VM creation, I can try and create a reproduction setup (if so far reproduction is the issue).

Assignee: nobody → jfkthame
Status: NEW → ASSIGNED

I was able to reproduce this on Ubuntu 20.04LTS after installing the older version of Latin Modern Math, per comment 51. Checked that setting line-height: 1.2 on the label fixes the issue here (and does not affect the rendering of "normal" titles at all).

(Using 1em as suggested in comment 46 would actually tighten the spacing slightly when second-line text such as PLAYING is present, so 1.2 is a better value to use here; it more closely reflects what normal computes to for typical user-interface fonts.)

Using 1em as I mentioned before does have caveats.

For my font (Cantarell), the bottom part of letters like "g" is trimmed. (e.g.: the part of letters that goes under the baseline. I'm sure that has a name).

With line-height: 1.2; this is still an issue, but with line-height: 1.3; it's not.

(That's called the "descender".)

Using 1.3 rather than 1.2 would certainly reduce the risk of clipping any of the glyphs. But at least when testing with the default Ubuntu UI font, I'm seeing that using 1.3 here causes the secondary tab label text (e.g. PLAYING), when present, to move down by 1 pixel from its current position. (The overall tab height doesn't change; just that second line of text shifts slightly lower within it.)

Personally, I think that still looks OK, and I'd be fine with using 1.3, but I'm not responsible for the design here; I think we need to hear from :jaws or others on the front-end team.

One other thing: note that there are other UI elements that are similarly affected, in particular entries in the URLbar dropdown (that's on file as bug 1671525) but also the tooltip that appears when you hover over such a tab. So a comparable fix should be applied to those as well, I think, but I'm not sure offhand where all the relevant CSS lives...

Points: --- → 1
Pushed by jkew@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/da82969d4cf5 Apply an explicit line-height to tab labels, in case the title uses fallback fonts with excessive ascent/descent metrics. r=jaws

https://hg.mozilla.org/mozilla-central/rev/da82969d4cf5

Status: ASSIGNED → RESOLVED
Closed: 4 years ago
status-firefox92: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 92 Branch
Flags: needinfo?(jaws)

Is this going to be uplifted to ESR91?

[Tracking Requested - why for this release]:

tracking-firefox-esr91: --- → ?

Please nominate this for ESR91 approval when you get a chance.

Flags: needinfo?(jfkthame)

Comment on attachment 9231908 [details]
Bug 1704404 - Apply an explicit line-height to tab labels, in case the title uses fallback fonts with excessive ascent/descent metrics. r?jaws

ESR Uplift Approval Request

  • If this is not a sec:{high,crit} bug, please state case for ESR consideration: Cosmetic but glaring UI issue with lots of dupes being reported
  • User impact if declined: UI layout occasionally gets disrupted - tabs may become much too tall, depending on title text and installed fonts
  • Fix Landed on Version: 92
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Narrowly-targeted CSS-only fix for tab sizing
  • String or UUID changes made by this patch:
Flags: needinfo?(jfkthame)
Attachment #9231908 - Flags: approval-mozilla-esr91?

Comment on attachment 9231908 [details]
Bug 1704404 - Apply an explicit line-height to tab labels, in case the title uses fallback fonts with excessive ascent/descent metrics. r?jaws

approved for 91.1esr

Attachment #9231908 - Flags: approval-mozilla-esr91? → approval-mozilla-esr91+

Given the volume of dupes and the low risk of the fix, I think we should have this on the radar for a 91 dot release too. Please nominate for release approval when you get a chance (no need to fill out the form again).

status-firefox91: wontfix → affected
Flags: needinfo?(jfkthame)
Flags: needinfo?(jfkthame)
Attachment #9231908 - Flags: approval-mozilla-release?
QA Whiteboard: [qa-triaged]

I've had difficulty reproducing this issue in the first place.

Joaquim Monteiro, would you verify this fix on your end?
It appears to be fixed in:

Al you need to do is set the system as initially had when the issue initially reproduced, download these 2 builds, run them and attempt reproduction.
Thank you for your contribution!

Flags: needinfo?(joaquim.monteiro)

Comment on attachment 9231908 [details]
Bug 1704404 - Apply an explicit line-height to tab labels, in case the title uses fallback fonts with excessive ascent/descent metrics. r?jaws

approved for 91.0.1 (release + esr)

Attachment #9231908 - Flags: approval-mozilla-release? → approval-mozilla-release+

Added to the 91.0.1 release notes:

Fixed an issue causing buttons on the tab bar to be resized when loading certain websites

relnote-firefox: --- → 91+

(In reply to Bodea Daniel [:danibodea] from comment #80)

I've had difficulty reproducing this issue in the first place.

Joaquim Monteiro, would you verify this fix on your end?
It appears to be fixed in:

Al you need to do is set the system as initially had when the issue initially reproduced, download these 2 builds, run them and attempt reproduction.
Thank you for your contribution!

The issue has been fixed since da82969d4cf5 landed on nightly. I can confirm it's also fixed in the 92.0b4 release you linked.

ESR 91 still has the issue, which is to be expected since it didn't receive the fix. In ESR 91.0.1 (which does have the fix applied), the problem is fixed.

Yes, that's right. Sorry to have provided the wrong build for ESR.
Thank you for verification in Nightly 93.0.a1, Beta v92.0b4 and ESR 91.0.1 and for the fast reply!

Would you kindly also verify the fix in Release 91.0.1?

status-firefox92: fixed → verified
status-firefox93: --- → verified
status-firefox-esr91: fixed → verified

(In reply to Bodea Daniel [:danibodea] from comment #86)

Yes, that's right. Sorry to have provided the wrong build for ESR.
Thank you for verification in Nightly 93.0.a1, Beta v92.0b4 and ESR 91.0.1 and for the fast reply!

Would you kindly also verify the fix in Release 91.0.1?

I can confirm it's fixed in 91.0.1 too.

Flags: needinfo?(joaquim.monteiro)

Thanks Joaquim!

Status: RESOLVED → VERIFIED
status-firefox91: fixed → verified
Flags: qe-verify+

I can confirm 91.0.1 fixed the address bar, but there are a number of outstanding locations with this issue (address bar suggestions, tab tooltips, history tooltips).

I've filed another bug for these remaining issues

https://bugzilla.mozilla.org/show_bug.cgi?id=1727397

(In reply to tony from comment #89)

I can confirm 91.0.1 fixed the address bar, but there are a number of outstanding locations with this issue (address bar suggestions, tab tooltips, history tooltips).

I've filed another bug for these remaining issues

https://bugzilla.mozilla.org/show_bug.cgi?id=1727397

Fixed the tab bar* to clarify

See Also: 1714276 →
See Also: 1716661 →
See Also: 1712663 →
See Also: → 1726757
See Also: → 1888724
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: