Regression 8.8: code display no longer scrolls horizontally

    We are using code view to post lo
g snippets that can contain quite lon
g lines. The way GitLab breaks these l
ines since EE 8.9 makes it totally wei
rd. Pre 8.9 it had a horizontal scrol
l bar.
   Is there an option to revert to th
e old behavior? Th
anks!

Not sure if this is EE only or CE, posting to CE, as both are likely affected.

This is simply a CSS issue. The old way was to allow horizontal scrolling, now the box word wraps.

ADD: Here's the problematic change: https://gitlab.com/gitlab-org/gitlab-ce/commit/25f592cf9c2d126625404df140dc5d958e8822cc (file detail_page.scss overrides white-space for <code> from pre to pre-wrap). It's title does not however suggest that the wrapping of code snippets was intended.

---

Verify fix:

This is a very long line that should scroll horizontally, not line-wrap. This is a very long line that should scroll horizontally, not line-wrap. This is a very long line that should scroll horizontally, not line-wrap. This is a very long line that should scroll horizontally, not line-wrap. This is a very long line that should scroll horizontally, not line-wrap. This is a very long line that should scroll horizontally, not line-wrap.

mentioned in issue #15635 (moved)

Changed title: Regression 8.9: code display no longer scrolls horizontally → Regression 8.8: code display no longer scrolls horizontally

Added frontend label

/cc @iamphill

related https://gitlab.com/gitlab-org/gitlab-ee/issues/837

Appreciate your attention to this issue! It might not seem a big deal at first, but think about tickets that already included log snippets, with some lines being 500+ characters wide, and none usually shorter than 150. Now they are all wrapped, ugly and unreadable.

@annabeldunstone want to talk about this again?

We could look into adding more specific CSS to allow scrolling of code blocks within snippets. We removed them because some lines of code were so long they seemed even more unreadable than if they were wrapping (I think this was true; it was a while ago).

Yes please! Code snippets are h-scrollable in GitHub, SO, Trac and JIRA, and I could not find a single counterexample. Also that's a regression (no way to do something one could do before). I believe that breaking changes in features should be announced to the customers in advance so they have a chance to choose whether to upgrade or freeze. I would go back to 8.7 just for this one feature.

@jschatz1 it would be great to fix this

@kkm can you post an example from our code base of some code that does this? I want to make sure we are talking about the same thing.

This is a very long line that should scroll horizontally, not line-wrap. This is a very long line that should scroll horizontally, not line-wrap. This is a very long line that should scroll horizontally, not line-wrap. This is a very long line that should scroll horizontally, not line-wrap. This is a very long line that should scroll horizontally, not line-wrap. This is a very long line that should scroll horizontally, not line-wrap.

@jschatz1: Looks like the issue has been fixed in 8.10, while it was present through 8.8 and 8.9. Currently, when I am looking at the CSS styles in debugger, I notice two changes. First, the style of the code box that contributes the white-space value is no longer code.wiki (according to my notes that are most likely correct); rather it is code.md. Second change is that the .md style override of white-space: pre-wrap has gone. I believe both changes were made in https://gitlab.com/gitlab-org/gitlab-ce/commit/f12e9705f273fef4856f2ba725b7a26f8e261eee.

~~So the issue can be closed as fixed. Except...~~guys, does not it unnerve you that both the bug and the fix were introduced apparently unintentionally? The first change was intended to control line wrapping in the diff view, and the second was, according to the description and merge notes, to add a border in Markdown preview. I am not one to tell you what to do, indeed, but I would review the inventory of CSS classes: Are not some of them reused in more places that they should?

Thanks for looking into it, in any case. I really appreciate the attention!

UPDATE: The issue is not fixed, my mistake! Code boxes scroll in comments and preview mode, but not in the ticket body itself after edits are committed. See "the very long line sample" in the body of the ticket I just added--if you Edit and Preview, it scrolls. The one in this comment scrolls in both edit preview and normal view modes.

mentioned in merge request !5675 (merged)

@kkm thanks for your feedback. Sorry to hear you are unhappy with the way things are right now:

@annabeldunstone and I did an extensive review of our current text wrapping situation. I recall that we had also had this discussion at length previously and had to make some very tough decisions previously.

The way this currently works is not a regression. It was intended.

The reason that code wraps is because when code scrolls in diffs it moves comments along with it making comments completely unreadable.

This same exact same thing happens in GitHub and we said that not being able to read comments and code at the same time was more of a problem than code wrapping.

The true solution to this is much more extensive and will take more time to implement which is to allow the code of diffs to scroll separate from the comments.

However as a intermediate fix we will make all triple back tick code samples scroll and all single back tick code samples wrap.

I've made this issue to tackle this fully. https://gitlab.com/gitlab-org/gitlab-ce/issues/20640

Thanks again for your input.

@jschatz1: here's the behavior of the code box in tickets:

• Ticket preview: scrolls
• Ticket normal view: wraps
• Ticket comment preview: scrolls
• Ticket comment normal view: scrolls

So, this was intended? After "an extensive review of our current text wrapping situation?" Good Consistency Lord, really? And what tickets have to do with diffs?

This is an answer, but not to the question I asked, sorry. The regression is in tickets, not diffs.

/cc @JobV re #15635 (moved). Here's the last nail to your "single consistent experience." Our setup was broken by new style, but this is "by design and not regression." This means I'll be mucking not only with GitLab code, but also recompiling the freaking omnibus assets on upgrades. I understand you guys have "philosophy" and "vision," but we your users have only PITA from these. It's a fatal disconnect. Good heaven, if I ever end up with a consistently working setup after this horrible chain of failed buggy upgrades, I'll freeze the thundering GitLab forever!

And I do not understand guys why this is a hard fix. Why do not you create a separate CSS class for diffs so that they can be styled separately from the tickets and from the wiki? I do not take this explanation as an answer at all, sorry.

So is there any reason why we can't have back the horizontal code scroll in tickets, and keep it disabled just with diffs (if that is truly required)? As @kkm mentioned and as can be seen in this ticket itself in the summary at the very top, horizontal scrolling seems to be broken right now

Status changed to closed by merge request !5675 (merged)

mentioned in commit 24477045

mentioned in merge request !14785