Open Bug 1636690 Opened 5 years ago Updated 2 years ago

Incorrect terminal width for asciinema terminal replays

Categories

(Core :: Layout: Text and Fonts, defect)

Product:
Core
Component:
Layout: Text and Fonts
Version:
75 Branch
Type:
defect

Tracking

()

Status:
UNCONFIRMED

People

(Reporter: shivam.src, Unassigned)

Details

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

Steps to reproduce:

When playing terminal recordings from asciinema (e.g. https://asciinema.org/a/133292), the terminal width is smaller and truncates the last few characters from the recording.

The issue was reported in 2016 on asciinema (https://github.com/asciinema/asciinema-player/issues/28) but is probably an issue from Firefox side.

Actual results:

A recording of 80 columns does not display as 80 columns but smaller. The CSS is assigned something like style="width:80ch;...." but only when that "width" value is removed the terminal show the correct size.

Expected results:

It should display the terminal as the defined width and no character should be truncated.

Chrome and other browsers work perfectly fine.

Because this bug's Severity is normal and has not been changed, and this bug's priority is -- (none,) indicating it has has not been previously triaged, the bug's Severity is being updated to -- (default, untriaged.)

Severity: normal → --

Hi,
I don't have the technical knowledge to confirm this issue but I'll add product and component so the team can make some research on it. Hopefully, someone with a more deep understanding of this matter can help. Feel free to route this ticket to the corresponding team.

Regards,
Jerónimo.

Component: Untriaged → CSS Parsing and Computation
Flags: needinfo?(svoisen)
Product: Firefox → Core

I can't reproduce this on OS X. Emilio can you reproduce this on Linux?

Flags: needinfo?(svoisen) → needinfo?(emilio)

I can't either. Reporter:

  • do you have any interesting font-size settings? (that is, does this reproduce with a clean profile?)
  • When the bug reproduces, what does the inspector's "fonts" panel show when you inspect one of the lines in the terminal? For example, for me it says "DejaVu Sans Mono" in the "Fonts used" section. It seems it's using the native "monospace" font, which means that if your local system has something that doesn't have the right font metrics, something like this should happen.
  • You mention that the rendering gets fixed by removing the width: <n>ch style. Does it become "bad" again if you add it back? Or does it remain "good"?

Thanks in advance.

Flags: needinfo?(emilio) → needinfo?(shivam.src)

Thank you Emilio for your response. I tried reproducing the bug under different circumstances and found that the bug appears only on my system where I have some special settings (which I can't figure out at the moment). However, as mentioned in the Github issue, other people have also witnessed the bug, so it is an existent bug.

My Setup

I am using Ubuntu 20.04 on Dell Latitude E5470 laptop with a 14" screen. The bug appears in my Ubuntu user account, even when using a clean firefox profile. However, I created a fresh user on my Ubuntu, and the bug did not appear on the Firefox in this account. I copied my Firefox profile to this new user and the bug did not appear. So, I must have done some changes in GNOME desktop or font settings which are causing this bug in Firefox (it doesn't appear in Chrome under any circumstances). I also tested it on Windows on the same laptop (dual-boot), and the bug didn't appear.

In summary, the bug is probably caused by some changes in the desktop environment settings (font or GNOME).

I will investigate further and try to reproduce the bug on fresh Ubuntu. Hopefully, I will be able to capture exactly what desktop setting is causing the bug.

Bug Demo

I have posted an animated GIF demonstrating the bug here: https://i.imgur.com/cPZbNWC.gifv

Answers to Queries

Here are the answers to your queries:

  • This bug also appears in a clean profile.
  • For me, it shows : "Bitstream Vera Sans Mono"
  • After restoring the width: <n>ch style, it becomes "bad" again.
Flags: needinfo?(shivam.src)

After restoring the width: <n>ch style, it becomes "bad" again.

Ok, that means that it's likely not a CSS bug per se, but a bug in font selection. I tried to set "Bitstream Vera Sans Mono" as my default monospace font in the gnome tweaks application, and I still didn't manage to repro the bug, so very curious if you find out what's going on...

Jonathan, do you have any idea about what may be going on here?

Component: CSS Parsing and Computation → Layout: Text and Fonts
Flags: needinfo?(jfkthame)

Not really. The reporter's screenshot looks like it's displaying Bitstream Vera Sans Mono with "normal" spacing, there's nothing obviously broken about the font rendering. The obvious cause for this would if the '0' glyph in the font (which is the basis for the ch unit) were narrower than the standard width of the rest of the glyphs (given that it's a monospace font), but it doesn't look broken in the screenshot. So I don't know what's going on...

Reporter, what format of Bitstream Vera fonts do you have installed -- are they .ttf files, or some other font format? Could you please attach a copy of your Bitstream Vera Sans Mono font file, so we can check exactly what version is involved? Thanks.

If you change font hinting settings (I think the Gnome tweak-ui tool can do this, for example) and then re-start Firefox, does that make any difference?

Flags: needinfo?(jfkthame) → needinfo?(shivam.src)

Okay. I have figured out it is because of the "Powerline Symbols" fonts installed inside my home directory in the ~/.fonts folder and configured inside the ~/.config/fontconfig/conf.d directory. I have shared both these folders in my dotfiles repository here: https://github.com/shivams/dotfiles

I installed a fresh Ubuntu 20.04 Virtual Machine and copied both these folder inside it, and the bug appeared! I did no other change on this fresh install, did not even install gnome-tweak-tool.

Flags: needinfo?(shivam.src)

Let me know if you are able to reproduce the issue now.

And as a further note, I had installed these Powerline fonts for the terminal from here: https://powerline.readthedocs.io/en/latest/installation/linux.html#fonts-installation

Interesting, so the font-family for that text is: Consolas, Menlo, 'Bitstream Vera Sans Mono', monospace, 'Powerline Symbols'.

Maybe were somehow using the ch width of the wrong font?

I think what's happening here is that the 10-powerline-symbols.conf file includes things like

	<alias>
		<family>monospace</family>
		<prefer><family>PowerlineSymbols</family></prefer>
	</alias>
... etc ...
	<alias>
		<family>Bitstream Vera Sans Mono</family>
		<prefer><family>PowerlineSymbols</family></prefer>
	</alias>

for a bunch of monospace font-family names. Because this uses <prefer>, it effectively inserts PowerlineSymbols ahead of Bitstream Vera Sans Mono in the font-matching process, and the width of its zero glyph becomes the basis for the ch unit.

Severity: -- → S3
You need to log in before you can comment on or make changes to this bug.