Weird Editor Bug: Offsetting cursor!

[mike_2000_17]

Hi,

I've been experiencing a weird bug in the editor (for a week or so). If I write a post, everything is fine and dandy until I start a block of code. From the first line of code that I write, and for every subsequent line of code after that, the cursor (the blinking line) gets offset by one pixel upwards. By the time I've written like 10-20 lines of code, the blinking line sits a full line above the place where I'm writing. The behavior continues after the code block is done (when writing normal text again), but the offset stops getting worse. The same offset applies to selecting some text that appears after the code.

This is quite annoying. I can always write the longer posts from a text-editor on the side and copy-paste the text back again, but I shouldn't have to do that.

Also, the blocks of code no longer appear in fixed-width font (when highlighted in the editor) like it used to. Writing code without a fixed-width font is very annoying.

FYI, I'm using Google Chrome, running under Linux (Kubuntu 11.10).

Anyone else experiencing the same problem? Dani, any ideas what the problem is? Solution?

[deceptikon]

Dani and I have been discussing it furiously for the last couple of days. Hopefully we'll have an idea of what's causing it soon.

[mike_2000_17]

Just to add more description. The same thing happens with inline-code.

I'm pretty sure this behavior is due to the fact that the code (inline or not) font in the highlighting is one pixel taller than the font on the normal text. And the cursor position seems to be calculated from the current_line_number * font_height_of_normal_text. That explains it, but doesn't solve it. I think you just need a more reliable method to get the vertical position where the cursor should appear. Or, you could just make sure that all the special fonts (code, links, bold, etc.) are all the same height as the normal font.

Also, about the fixed-width font for code. It appears that it is only a problem with the spaces at the start of the line (indentation!) that aren't the same width as the rest of the code letters. We keep talking about how important indentation is, it would helpful to have an editor that allows us to correctly indent easily.

[Dani]

Wait, so the code doesn't appear in a fixed width? Can someone please send me a screenshot. I cannot replicate this behavior.

Also, I'm confused how it's been happening for about a week. No changes to the editor or Javascript for the editor roughly that time ago. Screenshot please :) Sorry but I cannot replicate this for anything and that's the most frustrating part!

[Dani]

Also, what OS and browser are you using, and what browser version.

[Dani]

James, can you confirm it's been going on for about a week as well? Trying to match it up with something that changed in SVN.

[Dani]

We keep talking about how important indentation is, it would helpful to have an editor that allows us to correctly indent easily.

You can indent by hitting tab. What's easier than that?

[Dani]

Oh, also, can you confirm this happens with ALL editors (quick reply, new article, PM, etc)

[mike_2000_17]

Ok, I took the screenshots that you wanted.

And, I'm not sure that it has been a week, it could be only a few days.

[mike_2000_17]

Also, what OS and browser are you using, and what browser version.

My OS is Kubuntu 11.10:

Linux MPdesktop 3.0.0-20-generic #34-Ubuntu SMP Tue May 1 17:24:39 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

And my browser is Google Chrome version 19.0.1084.56-r140965:

Google Chrome   19.0.1084.56 (Official Build 140965)
OS  Linux
WebKit  536.5 (@119244)
JavaScript  V8 3.9.24.29
Flash   11.2 r202
User Agent  Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.56 Safari/536.5
Command Line     /opt/google/chrome/google-chrome --flag-switches-begin --flag-switches-end
Executable Path /opt/google/chrome/google-chrome
Profile Path    /home/mikael/.config/google-chrome/Default

[mike_2000_17]

You can indent by hitting tab. What's easier than that?

I can indent the entire code with tab, but that's not the point, see the snapshot.

And, yes, it occurs in all editors.

[Dani]

OK ... I think I might have fixed the problem.

[mike_2000_17]

I can confirm that the cursor problem is fixed.

However, the space size problem is not fixed.

[pritaeas]

Well, today in Opera 11.64 I discovered that when text is selected and then clicking the editor, the pasting appears stuck in a loop (pasting 63 quotes).

[Dani]

Can you explain what you mean, pritaeas? Huh??

[pritaeas]

I selected your sentence, clicked in the editor, result => see attached image (sorry, I forgot just now).

[Dani]

Does it do that in all browsers or just Opera?

[mike_2000_17]

It does not occur on Chrome.

[Dani]

DId it always do this in Opera?

[pritaeas]

Noticed this today. Don't use it much, so not sure, no earlier than friday.

[Dani]

Are you SURE you didn't have this issue earlier than Friday? We did upgrade to the latest version of the editor on Friday, but I can't see how it would have affected anything. I spent some time working on trying to fix it (I installed Opera and confirmed I was able to duplicate the issue). However, some other things took precedence today so I'll have another look at it a bit later.

[mike_2000_17]

What about the issue with leading spaces in the code blocks?

// This is why this problem annoying:
void some_function(int param1,
                                      int aligned_param2,
                                      int aligned_param3);

The spaces in the editor (only the ones at the beginning of the line) seem to be half the width they should be. (see attachement)

[pritaeas]

Are you SURE you didn't have this issue earlier than Friday?

No. Like I said, I try not to use this "feature". Appears to be doing it with a copied block too. If I select text, copy it, then click the selection away in the screen, then click the editor, same thing happens (but not if I do this in my own post).

[deceptikon]

Well, today in Opera 11.64 I discovered that when text is selected and then clicking the editor, the pasting appears stuck in a loop (pasting 63 quotes).

I was able to reproduce the issue and pushed a fix to our staging environment. It's now pending Dani's approval.

[mike_2000_17]

Bump.

Any hopes on getting fixed width spaces in the code editing environment ?

[Dani]

The offset cursor bug should be fixed. I'm confused what you mean by fixed width spaces? I don't really understand the screenshot you posted.

[mike_2000_17]

what you mean by fixed width spaces? I don't really understand the screenshot you posted.

In the screenshot I posted, I write a function declaration with "long" parameter names. So, for readability, I want to put each parameter on a separate line and align them such that they fall one underneath the other (i.e., left-justified from the opening parenthesis of the function). This is what I typically do in such cases. In the screenshot, you can see that I wrote the code in the editor code-highlighted-environment with the right number of spaces such that they fall in alignment. However, the width of the spaces in the editor code-env. does not correspond to the width of the spaces in the resulting posted code (the ratio seems to be one half). As a result, the code that gets posted is completely misaligned, even though I wrote it to be aligned.

As you know, in the coding font, all letters have the same width. This holds true for all letters (or other characters) in the editor's code-env., and for all spaces in-between other characters or words. But, for the spaces that begin the line, they do not have the same width as all other characters, they appear to have half the width of other characters. As so:

this is one line of code.
    <-- here I added 4 spaces, but, in the editor, the cursor appears between the 'h' and 'i' of the word 'this' above (2 character-widths only)

It is quite incovenient to have to look at the live preview to align variables and do proper indentation, instead of coding in the editor, and looking only at the editor.

BTW, it appears, right now, that the offset cursor bug has returned! But now the cursor is offsetting in the other direction (appearing lower than the text). I'm gonna provide more details as I figure out what seems to cause it, because I'm not able to reproduce it all the time.

[Dani]

The offset cursor bug becomes prevalent when a line of code wraps to the next line.

[mike_2000_17]

Yep, that's what triggers it.

Did you understand my explanation of the fixed-width space problem? Any ideas?

[Dani]

Still struggling with the offset cursor bug. I'm usually really good at CSS, but this is royally kicking my ass!