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
394.80 KB, image/png
93.93 KB, image/png
Created attachment 8783189 [details] 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
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)
Created attachment 8783193 [details] Screenshot showing Archlinux/FF Nightly where this bug DOESN'T occur for some reason
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
Status: UNCONFIRMED → NEW
Component: Untriaged → Layout: Text
Ever confirmed: true
Product: Firefox → Core
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.
(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.
(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.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WONTFIX
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.
Status: RESOLVED → REOPENED
Component: Layout: Text → Desktop
Product: Core → Tech Evangelism
Resolution: WONTFIX → ---
Version: 51 Branch → unspecified
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.
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?
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.
You need to log in before you can comment on or make changes to this bug.