4

This question already has an answer here:

When looking at this question and scrolled down the codeblock I saw this:

enter image description here

Under the horizontal scroll bar there is a blank area still in the codeblock. I have never seen this before so I thought it might be a bug?

I just noticed that the question was edited and it is normal again now but I would still like to know if this is a common thing or not.

Edit:
I can reproduce this in:
-Google Chrome version 33.0.1750.117 m.
-FireFox 26.0
-Internet Explorer 11.0.9600.16518

OS:
Windows 7 Professional.

marked as duplicate by ShaWiz, Martijn Pieters, hims056, Josh Crozier, Gilles Feb 24 '14 at 20:04

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • Can't reproduce. Please provide more details. Things like your browser + version and OS + version. – Oded Feb 24 '14 at 11:23
  • Looks like a browser bug. – ShaWiz Feb 24 '14 at 11:34
  • Most likely you have some rough extension or user script causing this then. Disable them all until you find which of them is causing the problem. – ShaWiz Feb 24 '14 at 12:13
  • 1
    @ShadowWizard I am not running any extensions or user scripts, I have tested multiple browsers and I can reproduce it in all of them. – Daanvn Feb 24 '14 at 12:26
  • That's really weird then. Just to reassure it's no-repro, I'm using same browser and OS and see this. Does it happen for you on all code blocks with horizontal scrollbar? – ShaWiz Feb 24 '14 at 12:36
  • @ShadowWizard I do not see it in every code block, I only see it in the one I mentioned and can only see it in the revision page now. I am still seeing this. – Daanvn Feb 24 '14 at 12:45
  • @Daanvn eureka! Can reproduce now. Need to scroll down to the bottom. Hmm... – ShaWiz Feb 24 '14 at 12:49
  • 2
    @Oded can you try to reproduce with Chrome in this revision? Scroll the code block to the bottom and see what happens. – ShaWiz Feb 24 '14 at 12:58
  • I can see this too in Chrome 32 - only when I scroll to the bottom – CodingIntrigue Feb 24 '14 at 12:59
  • Confirmed on Chrome v33. I guess it caused by <pre> on first post 1st post source. after removing <pre> in second revision, its no longer visible 2nd revision source. – Omar Feb 24 '14 at 13:02
  • OK, not sure it's considered a bug. <pre> tags should not be used for code blocks, hence it's breaking the formatting. – ShaWiz Feb 24 '14 at 14:25
6

It seems to be a bug in the way the Markdown parser handles code that is both indented and wrapped in <pre> tags.

Specifically, the source for the original version of the question looks like this:

<PRE>

SELECT      
        SECU.SECID,     
        SECU.DENOM,     
[...]
    AND SECU.VDATE <= '12/26/2013'      
    AND W1.OBSSCHEDID = T_OBSSCHED.OBSSCHEDID)

</PRE>

This really confuses the Markdown parser and causes it to emit totally screwed up HTML with two nested <pre> tags:

Screenshot of broken HTML in Chrome developer tools

You may also notice a bunch of <p> tags nested inside the outer <pre>, which is also a big no-no.

In fact, trying to validate the resulting HTML reveals that it's even more broken than the Chrome developer tools show, with a whole bunch of mismatched open / close tag pairs:

Screenshot of HTML5 validator results

The actual HTML code generated by the Markdown parser looks like this:

<p><PRE></p>

<p>SELECT<br>
        SECU.SECID,<br>
        SECU.DENOM,<br>
        SECU.INTPAYRULE,<br>
        SECU.INTENDDATERULE,<br>
        SECU.SCHEDID,<br>
        SECU_CONV.MATURITYIND,<br>
        SECU_CONV.ACCROUTSTIND,<br>
        SECU_CONV.NEWSECID,     </p>

<pre><code>    CASE WHEN W2.OBSENDDATE IS NULL THEN SECU.VDATE ELSE W2.OBSENDDATE END AS STARTDATE,    
    W1.OBSENDDATE AS ENDDATE,   
    T_OBSSCHED.TYPE AS TYPE,    
[...]
AND SECU.VDATE &lt;= '12/26/2013'      
AND W1.OBSSCHEDID = T_OBSSCHED.OBSSCHEDID)
</code></pre>

<p></PRE></p>

Basically, it appears that the indented code block is parsed normally, while the literal <pre> tags are simply passed straight to the HTML output with no regard for document structure.

IMO, the right way to fix this would be to turn off all Markdown paragraph / linebreak / list / code block parsing for any content between <pre> and </pre> tags. Basically, the only processing done to the literal text between those tags should be to filter out non-whitelisted HTML tags.

Ps. Yes, the SE Markdown parser should be able to do this, since it already disables several other kinds of Markdown syntax inside <pre> tags; for example, the code:

<pre>This is *not* in italics, but <i>this</i> is.</pre>

produces:

This is *not* in italics, but this is.

Edit: It also turns out that, for some reason, the Markdown parser is treating <pre> and <PRE> differently:

<PRE>This should *not* be in italics, but it is.</PRE>

produces:

This should not be in italics, but it is.

Presumably, somewhere in the parser there's a case-sensitive check for "pre" that should really be case-insensitive.

However, simply changing the <PRE> tags in the linked post to lowercase doesn't fix it — it just makes it break in a different way, with the content being dumped into the output completely unformatted. Clearly, there's more to this bug than just that.

  • Thanks for the clarification/explanation! – Daanvn Feb 24 '14 at 13:44

Not the answer you're looking for? Browse other questions tagged .