Items are not aligned in tree view

RESOLVED FIXED in Firefox 69

Status

()

enhancement
P3
minor
RESOLVED FIXED
2 months ago
Last month

People

(Reporter: arai, Assigned: njn)

Tracking

Trunk
mozilla69
Points:
---

Firefox Tracking Flags

(firefox-esr60 wontfix, firefox-esr68 wontfix, firefox67 wontfix, firefox67.0.1 wontfix, firefox68 wontfix, firefox69 fixed)

Details

Attachments

(3 attachments)

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

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.

Flags: needinfo?(jfkthame)
Priority: -- → P3

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.)

Flags: needinfo?(jfkthame)

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

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

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

Flags: needinfo?(arai.unmht)

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.

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.

Flags: needinfo?(arai.unmht)

(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?

Flags: needinfo?(mh+mozilla)
Attachment #9074735 - Attachment is patch: false
Attachment #9074735 - Attachment mime type: text/plain → image/png

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

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"
Flags: needinfo?(mh+mozilla)
Attachment #9074691 - Attachment description: Bug 1561153 - Explicitly set `lang="en"` for about:memory. r=jfkthame → Bug 1561153 - Fix problems with box-drawing chars in about:memory. r=jfkthame

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

Flags: needinfo?(mh+mozilla)
Flags: needinfo?(arai.unmht)

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 :)

Flags: needinfo?(arai.unmht)

WFM too.

Flags: needinfo?(mh+mozilla)
Pushed by nnethercote@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/6d855f154cd7
Fix problems with box-drawing chars in about:memory. r=jfkthame
Status: NEW → RESOLVED
Closed: 2 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla69
Assignee: nobody → n.nethercote
Regressions: 1563722
QA Whiteboard: [qa-69b-p2]
You need to log in before you can comment on or make changes to this bug.