1561153 - Items are not aligned in tree view

Status: RESOLVED FIXED

(Toolkit :: about:memory, enhancement, P3)

Description

[Tooru Fujisawa [:arai]]

Attachment: screenshot of about:memory

Steps to reproduce:

1. Run Firefox Nightly 69.0a1 (2019-06-24) (64-bit) with clean profile, on macOS 10.14.5, japanese environment
2. open about:memory
3. check "verbose" in "Show memory reports" section
4. click "Measure" in "Show memory reports" section
5. wait for report to be filled
6. collapse all items under "Main Process" - "Explicit Allocations", by clicking each item

Actual result:
get screen like the attachment image
"B" in items are not aligned, and it looks like there are some yet another parent-child relation between items
I suppose it's due to the different font width between numbers/comma and "─"

Expected result:
"B" in items are aligned

Comment 1

[Nicholas Nethercote [inactive]]

Thank you for the bug report. As you suggest, it looks like the following characters are drawn twice as wide as ASCII chars in your configuration:

• U+2500 BOX DRAWINGS LIGHT HORIZONTAL (U+2500) ─
• U+2514 BOX DRAWINGS LIGHT UP AND RIGHT (U+2514) └
• U+251C BOX DRAWINGS LIGHT VERTICAL AND RIGHT (U+251C) ├

jkew, any idea why these chars are double-wide in a Japanese environment, and how this could be fixed? The font used for about:memory is Firefox's internal message-box font, see here. Thanks.

Comment 2

[Jonathan Kew [:jfkthame]]

Actually, the message-box font isn't what we're seeing there; the bulk of the about:memory content is inside <pre class="entries">, and html.css sets font-family: monospace for <pre>.

So the question, then, is what font family is configured as monospace for the locale involved, whether it really is monospaced, and whether it supports the box-drawing characters.

In English with default Firefox prefs, the default monospace font is Courier; as it happens, this doesn't support the box-drawing characters, but the font prefs also include Courier New as a fallback, and it does have these characters -- and fortunately, it has the same character widths as Courier, so the resulting mixture of fonts doesn't disrupt alignment.

However, if I set lang="ja" on the <pre> element in about:memory, the default monospace font is Osaka-mono (note: this depends on having the Osaka fonts activated in Font Book; they're not present by default on an English system, but are downloaded if you explicitly ask Font Book to enable them). The problem then arises because Osaka-mono is not truly "monospaced": it has Latin letters that are exactly half the width of its Japanese Kanji/Kana glyphs. (This is usually a good thing, because full-width Latin letters used for any significant quantity of text look really ugly.) The trouble is that the box-drawing glyphs in Osaka-mono have (quite reasonably) the same "full" monospaced width as Japanese characters, and therefore are twice the width of its Latin letters/digits.

A similar issue occurs with Chinese locales, by the look of it.

Probably the simplest fix would be to explicitly tag the language of the about:memory content with lang="en", so that English font prefs are used to resolve the font-family: monospace property on the <pre> elements.

(Do we localize about:memory in localized Firefox builds? If so, that may complicate things a bit; but the screenshot here, at least, shows English content for which lang="en" would be entirely appropriate.)

Comment 3

[Nicholas Nethercote [inactive]]

Thanks for the detailed answer, jkew! We do not localize about:memory, so leng="en" sounds good to me.

Comment 4

[Nicholas Nethercote [inactive]]

Attachment: Bug 1561153 - Fix problems with box-drawing chars in about:memory. r=jfkthame

This avoids problems with double-width box-drawing chars in Japanese and
Chinese locales.

Comment 5

[Nicholas Nethercote [inactive]]

arai, can you please try the patch and see if it fixes the problem for you?

Comment 6

[Mike Hommey [:glandium]]

I'm not arai-san, but I can see the same thing and if I open about:memory, save it to a file, edit that file to add lang="en", and open the modified file, I'm still getting misalignments.
The font I get for the treelines is Noto Sans Mono CJK JP, for some reason, and for numbers, it's Noto Mono. But it's the treelines that create the misalignment.

Comment 7

[Tooru Fujisawa [:arai]]

Attachment: screenshot of about:memory, patch D36287 applied

Thanks!

The patch fixes the issue for me.
I've tested on m-c 741452096055 and D36287 applied, artifact build, and same env as comment #0, and I get the attached screenshot.

I've checked devtools font panel and the box-drawing characters are rendered with Courier New, that's
set as monospace for for Latin, in about:preferences.

I don't have a font named "Noto Sans Mono CJK JP".
I have "Noto Sans Japanese" listed under monospace dropdown menu, but that's not selected.

Comment 8

[Jonathan Kew [:jfkthame]]

(In reply to Mike Hommey [:glandium] from comment #6)

I'm not arai-san, but I can see the same thing and if I open about:memory, save it to a file, edit that file to add lang="en", and open the modified file, I'm still getting misalignments.
The font I get for the treelines is Noto Sans Mono CJK JP, for some reason, and for numbers, it's Noto Mono. But it's the treelines that create the misalignment.

Which platform are you on -- I'm guessing Linux? Sounds like your fontconfig setup maps 'monospace' to Noto Mono, but Noto Mono doesn't support the box-drawing characters; so then it falls back to Noto Sans Mono CJK JP, which has a different character width.

If you change your font prefs to select Fira Mono as the default monospaced font for Latin, I suspect that would probably fix it, as Fira Mono does support the box-drawing chars. But as long as we're trying to respect the fontconfig generics, it's hard to see how we can entirely avoid the risk of something like this, short of a major rethink of how about:memory draws the tree.

Maybe we should explicitly style the <pre> with some likely font family names that are known to support the chars needed, so that if any of them are present things will line up nicely, and we'll only hit the monospace generic (which is a bit risky as it depends how the individual system is configured) if none of the known-good fonts are available. I suspect any of DejaVu Sans Mono, Fira Mono, and Liberation Mono would be OK, and probably others out there...

So if you add a style rule like

pre { font-family: Fira Mono, DejaVu Sans Mono, Liberation Mono, monospace; }

does that help?

Comment 9

[Mike Hommey [:glandium]]

It does. DejaVu Sans Mono is picked, and that looks good (I don't have Fira Mono). If I remove DejaVu Sans Mono, Liberation Mono is picked (because I have it), and that looks good too. So at least those two are adequate.

Probably related: https://github.com/googlefonts/noto-fonts/issues/617

Comment 10

[Mike Hommey [:glandium]]

FWIW:

$ fc-match monospace
NotoMono-Regular.ttf: "Noto Mono" "Regular"
$ LANG=en_US.UTF-8 fc-match monospace
NotoMono-Regular.ttf: "Noto Mono" "Regular"
$ fc-match serif
NotoSerifCJK-Regular.ttc: "Noto Serif CJK JP" "Regular"
$ LANG=en_US.UTF-8 fc-match serif
DejaVuSerif.ttf: "DejaVu Serif" "Book"

Comment 11

[Nicholas Nethercote [inactive]]

glandium, arai: can you both try the new patch? Thank you.

Comment 12

[Tooru Fujisawa [:arai]]

Confirmed the fix, D36287 Diff 2 applied to m-c adc59d50adf8, artifact build, same env as #0.
box drawing characters are rendered with "Courier New", numbers and alphabet are with "Courier",
"B" in items are aligned :)

Comment 13

[Mike Hommey [:glandium]]

WFM too.

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/6d855f154cd7
Fix problems with box-drawing chars in about:memory. r=jfkthame

Comment 15

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/6d855f154cd7