Don't cut off line counts needlessly on the website


Line counts (as in: number of total/covered/uncovered lines in a file) on the website are cut off if they have 6 or more digits, despite there being plenty of horizontal space. Moreover, if the browser window is narrow (e.g. on a mobile device) they are often cut off even after just 4 or 3 digits or even just a single digits – again, despite there being plenty of horizontal space.

I previously reported this to the support email on 5 September 2018 (and before that in the old support Slack).


In “Files” views on, line counts are cut off once they have more than 5 digits. It doesn’t matter how wide I make the window, 6 digits line counts are shown like this: 108,161…

But it gets much worse if the browser window is narrower than something around 1000 pixels. Then all line count data with 4+ digits gets cut-off after just one digit, and thus becomes totally useless – and this despite there being plenty of space being available.

Attached you’ll find a screenshot from to illustrate my point; but the issue is visible anywhere line counts are shown, e.g. on

In the screen shot, note that on the left and right sides, as well as right of the file names, there is lots of screen real estate available; but the columns with line counts are made needlessly narrow, and then are cut off, making them completely useless. E.g. it’s impossible to tell that the “1…” in the fifth row denotes a larger quantity than the “5…” right of it.

Needless to say, this means line counts are useless on tablets and phones (and yes, that matter to some of us). But also if one wants to view to Codecov pages side by side in two browser window, to compare coverage between two commits (e.g. because Codecov PR views have been broken for some time and always timeout… another issue I reported).


See above resp. the screenshot below


Irrelevant. Is an issue of the website CSS.

1 Like

(post withdrawn by author, will be automatically deleted in 24 hours unless flagged)

Thanks for this @fingolfin --> we are going through a redesign in our UI currently and this has made it into our wire frames.

Any news on that? On the website it’s as bad as it always was.

(But I noticed the codecov.yml documentation was finally improved. It went from almost completely useless to pretty comprehensive. Kudos!)

Thanks for the kudos @fingolfin – that documentation was written by @drazisil, who did a great job!

Re: cutting off numbers, we are smoke testing currently our new frontend framework, and will ship the redesign on top of the new frontend.

Slow, but steady progress! Appreciate your patience. With the refactored framework, we will be able to UI bugs like this much faster.

Sadly after 3.5 months, this is still an issue (actually, it’s more like 3.5 years by now, but who’s counting sigh)

1 Like

Hi @fingolfin, thanks for continuing to push on this. We are still working towards our UI refresh. I’ll make sure this continues in our mocks and implementation.

@fingolfin exciting, if not incredibly belated, progress! On the left is the refactored frontend.

@jerrod sorry, never saw your posting.

I was about to post here to ask whether any progress was made, because it still doesn’t work. E.g. on Code coverage done right. it is still looking bad.

Then I reloaded that page, and for some reason still unclear to me, it suddenly redirected me to Codecov (I have not yet been able to reproduce that). And there, lo-and-behold, it is fixed! Of course the coverage colors are completely borked, but I guess can’t have everything…

So perhaps that means that’s the “refactored frontend”, but for some reason it is not the default? Or what is going on here?

@fingolfin, we are working to redesign our frontend which is why you get redirected to app.. Since we are moving (slowly) towards the new frontend, we will likely not fix this on the legacy frontend. Apologies for the misdirection here.