User blog comment:Kirkburn/Syntax highlighting - helping you read and write code/@comment-452-20150410203600/@comment-452-20150413145916

@452 I prefer fixing it to disabling it. It is your personal choice to continue using it and waiting for it to be fixed, and I fully respect your personal choices. The fact that I am requesting the opinion to not use it for myself does not effect your personal choice to continue using it.

Does this match what you're seeing No.

If it were as convoluted as you just described, then it would be my fault it was happening. The fact that you considered that convoluted method to reproduce this implies that you think I'm trying really hard to find obscure problems.

This "just happens" for me when the line is on-screen vertically, but the string is off-screen horizontally.

Whether you can replicate it does not change the fact that this is one of the many problems happening for me, therefore I would like the option to turn it off for myself on all wikis.

Even if you did manage to fix this one issue, I highly doubt you would be able to disable the native-browser search, so the problem would remain that "The native browser search cannot find text which is off-screen vertically because the "syntax highlighting script" breaks standard functionality by not rendering it."

As you can see in the screenshot, the custom search bar is not present. There are two possible explanations for this: Which one of these options do you think is true?
 * I deliberately closed it after using it in order to deceive you.
 * I didn't use the custom search bar.

In this case, the fact that Wikia has disabled user CSS and JS when editing JS pages actually helps me for once, because we can immediately eliminate the third option of "user JS/CSS is causing an issue which wouldn't normally occur".

I'm sorry about the instances where I've mistakenly reported issues which were caused by my personal customizations, but I have never actively attempted to deceive you about any bugs I've experienced.

edit: Just in case I "accidentally" did what you suggested, I just checked again, and it still occurs exactly as I've described it.

Here is a screenshot of the page source.

Note that the mouse is hovering over the lighter-blue element, .ace_scrollbar-h, which is causing the rendered scrollbar to be highlighted.

This is not a "normal" scrollbar. A "normal" scrollbar is actually attached to the element in scrolls. Apparently, some javascript is being used so that when this custom scrollbar is used, the content element is also offset to the same amount. This is essentially reinventing the wheel.

The content is actually in .ace_content, you can see in the screenshot that it has a width of 11284px. However, this is inside the element .ace_scroller, which is set as "overflow: hidden", which in laymen's terms means "don't show a scrollbar".

However, content in a overflow: hidden container can still be scrolled either by dragging, or by using the default browser search to forcible scroll the container so that the content is on-screen.
 * Edit: Bonus proof: after successfully replicating this, and changing the "overflow: hidden" style to "overflow: scroll" (it defaults to "overflow: visible when disabled"), a second set of "real" scrollbars appears on the .ace_scroller</tt> element, offset to the correct place.

This is why this is occurring.


 * edit: my example below cannot be dragged to the right, I'm unsure why, but searching still works, and that's what's important in this case.

This is a div, with the style width: 10000px;</tt>, inside a overflow:hidden;</tt> div.

When you search for the word "test ing" without a space in the middle, this div will be offset about 10000px to the right, without a scrollbar.

testing

hóper édei deîxai