1296856 - Render bug with Gitlab source code view, only happens with SOME linux distributions and environments

Status: RESOLVED WORKSFORME

(Web Compatibility :: Site Reports, defect, P3)

Description

[Jonas Thiem]

Attachment: Screenshot demonstrating the bug in an affected configuration - look closely at the line numbers around line 59 and how they don't line up with the code

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0
Build ID: 20160819030226

Steps to reproduce:

There appears to be a render bug with Gitlab source code view. I think it's a firefox problem and not a site problem because it only appears on Linux, and only on some machines I have seen. For example, Archlinux with some more obscure window manager with Firefox Nightly works fine, but Fedora with GNOME 3 with Firefox Nightly is broken.

To reproduce, you need to:
1. Run an affected configuration (e.g. Fedora 24, Gnome 3 desktop, Firefox Nightly with Developer Theme enabled and set to dark, and global dark theme enabled in the gnome tweak UI):
2. Visit a source code listing on a gitlab instance, e.g. https://gitlab.wobble.ninja/JonasT/wobbly/blob/master/tools/baseline-runner.py


Actual results:

Scroll down to line 59. If your configuration is affected, there will be an obvious strong mismatch between the line number and the line - also see attached screenshot


Expected results:

Line numbering lines up with actual code lines correctly

Comment 1

[Jonas Thiem]

FWIW I tested this with safe mode and a fresh profile on F24/GNOME 3/Firefox Dev Edition too, and it happens as well. (adding this because the screenshot wasn't made on a clean profile)

Comment 2

[Jonas Thiem]

Attachment: Screenshot showing Archlinux/FF Nightly where this bug DOESN'T occur for some reason

Comment 3

[Tooru Fujisawa [:arai]]

Reproduced with Nightly (2016-08-20) on Fedora 24 GNOME 3.20.2.

On affected case, font-weight changes the height of the line.

Class like "o", "kn" have "font-weight: bold".  those are used for span element enclosing "import", "=" etc in the code.

Code line (span with id="LC*") that doesn't contain those bold text but normal text like class="nn" have 19.5px height.
Code line that contains those bold texts has 20px height (+0.5 extra height),
while all line numbers (span with id="L*") have 19.5px height,
that results in the mismatch between line number and code.

Here's summary for affected case and not affected case

                 | Fedora (affected)    | Ubuntu (not affected) | OSX (not affectd)
-----------------+----------------------+-----------------------+-------------------
 font of "kn"    | Liberation Mono Bold | Liberation Mono Bold  | Menlo Bold
 height of "kn"  | 11                   | 15                    | 17
 font of "nn"    | Liberation Mono      | Liberation Mono       | Menlo Regular
 height of "nn"  | 10                   | 15                    | 17
 height of "LC*" | 19.5 or 20 (with kn) | 19.5                  | 19.5
 height of "L*"  | 19.5                 | 19.5                  | 19.5

Comment 4

[Xidorn Quan [:xidorn] UTC+11]

Given neither Ubuntu nor Arch is affecred, could this be a bug of fontconfig or the font Fedora includes? It seems to me height of text is basically ascent+descent, and both values are from font.

Comment 5

[Tooru Fujisawa [:arai]]

(In reply to Xidorn Quan [:xidorn] (UTC+10) from comment #4)
> Given neither Ubuntu nor Arch is affecred, could this be a bug of fontconfig
> or the font Fedora includes? It seems to me height of text is basically
> ascent+descent, and both values are from font.

apparently, the issue comes from font file.
when I replace LiberationMono-Regular.ttf and LiberationMono-Bold.ttf with Ubuntu's files, the issue disappears.

Comment 6

[Xidorn Quan [:xidorn] UTC+11]

(In reply to Tooru Fujisawa [:arai] from comment #5)
> apparently, the issue comes from font file.
> when I replace LiberationMono-Regular.ttf and LiberationMono-Bold.ttf with
> Ubuntu's files, the issue disappears.

I guess that means we should resolve this bug as WONTFIX or INVALID, then, given this is bugs in Fedora's font file, not our side, and can be fixed via replacing the file with that from other systems.

Comment 7

[Jonathan Kew [:jfkthame]]

Actually, I think we should consider this a Tech Evangelism bug: it looks like the problem is that the Gitlab source view is relying on separate elements (with different font properties) getting the same automatic line spacing, which is an inherently fragile assumption to make. If they want to have line numbers and code in side-by-side elements lining up with each other, they need to set an explicit fixed line-height, NOT rely on something automatically derived (in potentially browser/platform-dependent ways) from (platform-dependent) fonts.

Do we have contacts at Gitlab at all? We should encourage them to make their CSS more robust against variable font configurations.

Comment 8

[Jonas Thiem]

For what it's worth, I also filed a bug with gitlab: https://gitlab.com/gitlab-org/gitlab-ce/issues/20202 but it didn't receive much attention at all - I guess probably because it's only such a rare configuration that is actually affected, so pretty much nobody else has run into it.

Comment 9

[Jonas Thiem]

Just for what it's worth (since gitlab itself isn't really responding at this point), I tried a fixed line-height that is way larger than the font (25px line height, font is at 13px size according to "Inspect") and even specifying that doesn't make it line up. Is line-height truly independent of whatever the font does?

Also a bold font changing line height still seems super fishy. Maybe I should forward this bug to Fedora as well?

Comment 10

[fr.sc]

Just for information: I'm experiencing the same problem on Ubuntu 14.04 with Firefox 49.
GitLab specifies a min-height: 19px to their code line spans. I tried setting min-height: 1.5em instead and this seems to fix it.

Comment 11

[Mike Taylor [:miketaylr]]

Jonas, since https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/6485 landed, can you reproduce anymore?

Comment 12

[u580221]

Sorry, I forgot about this ticket (I'm the original poster, I have a different e-mail address now): since that fix was shipped, it works fine for me. As far as I'm concerned, this can be closed. However, keep in mind I can't judge if there's nevertheless something in Firefox that should be improved to make this less likely to happen in the future or something - but Gitlab definitely works fine now with their change.

Comment 13

[Mike Taylor [:miketaylr]]

Thanks jonas. Yeah, it's possible there's a real bug here that we don't understand. But without a testcase or site where this repros today, it will be hard to make any progress. Let's go ahead and close.