Cursor position / font weirdness

[GoogleCodeExporter]

What steps will reproduce the problem?

1. Type a long line, watch the cursor position.

What is the expected output? What do you see instead?

The cursor should be where the next character will render.

Instead, it lags more and more as I type, about 1 for 15.
That is, every 15 characters, it is one character more displaced left.

What version of the product are you using? On what operating system?

Firefox 3.07, probably Andale Mono is the default monospace font.

Please provide any additional information below.

NOTA BENE: The problem is NOT occurring with Linux Firefox 3.07 and Linux
default Monospace font.  I conjecture that this is a font metrics problem?

But I don't know if the problem is with shellinabox or with the font?

Possibly this is really a bug with Microsoft's Andale Mono font?

Or maybe it is a bug with how shellinabox javascript figures out the metric
for where to put the cursor?  I don't know the heuristic...

Original issue reported on code.google.com by TomOeh...@gmail.com on 18 Mar 2009 at 6:31

[GoogleCodeExporter]

Hmm, I tried changing my default monospace font to courier new but shellinabox 
used
the same font still, which is NOT courier new, so, I don't really understand 
how it
is picking it's font, or WHAT font is the one having the problem.  All I know 
for
sure is  that the problem occurs under my Windows XP Firefox 3.07, but not 
under my
Linux Ubuntu Firefox 3.07 (which definitely uses a _different_ font...)

Original comment by TomOeh...@gmail.com on 18 Mar 2009 at 6:34

[GoogleCodeExporter]

Hmm, I disabled "allow applications to pick their own fonts"; now shellinabox 
uses
the font I tell it to, but, it puts the cursor in the wrong place always.  
Maybe it
is related to screen resolution / dpi ?  I'm running Windows XP with a 104dpi 
setting
in the "display => settings => advanced => DPI setting".  That effects how many
pixels the fonts take up...

Original comment by TomOeh...@gmail.com on 18 Mar 2009 at 6:40

[GoogleCodeExporter]

This almost certainly sounds like a defect in the font that your browser picks. 
I
have seen fonts that are only "almost" monospaced. That would certainly be a 
problem
for ShellInABox. This can also happen, if the browser doesn't find all the 
glyphs in
a particular font and substitutes them from other fonts. Not sure if that's 
happening
in your case.

In either case, you can experiment with editing styles.css. Maybe, one of the 
fonts
that ShellInABox suggests is actually bad? You can use the --static-file= 
command
line argument to override styles.css

Original comment by zod...@gmail.com on 18 Mar 2009 at 7:22

[GoogleCodeExporter]

Minor further information, now that I have IE6 working on that machine, this 
problem
only occurs on Firefox.

Original comment by TomOeh...@gmail.com on 19 Mar 2009 at 11:28

[GoogleCodeExporter]

Ha- spoke too soon.  IE gets the _horizontal_ correct, but the _vertical_ is 
off!

Really funny looking in both cases.  If I use Firefox, and edit a file in vi, 
and get
down to the lower right of the screen, Firefox has the cursor a half inch left 
of the
"real" cursor, IE has the cursor a couple of lines above the real cursor!

I wonder if there is a way to do the cursor with manipulation of text, maybe 
swapping
the character with "|" back and forth, or flipping the "reverse" attribute back 
and
forth on the character?

Nota Bene: This issue occurs on IE on a clean clean vmware install of windows 
2000
and IE6, so it isn't due to some weird non-standard font setup.

So far, the problem NEVER happens with a Linux browser.

Original comment by TomOeh...@gmail.com on 19 Mar 2009 at 11:38

[GoogleCodeExporter]

I made a bunch of changes that should avoid the problem in most cases.

It is not clear, whether it can be fixed in all cases, as we want to be able to
position the cursor to parts of the screen that don't have text. This is 
necessary so
that copy&paste works as expected.

In the cases where the cursor is not adjacent to any text, we use the old 
algorithm
and might still get the position wrong.

But in all other cases, we position the cursor relative to the text.

I also tweaked some style sheet settings that might have caused trouble with 
some
browsers.

Let me know, if things look better for you, now. Please also do test cursor
positioning after a long sequence of space characters, as that could still be 
broken.

Original comment by zod...@gmail.com on 19 Mar 2009 at 10:22

[GoogleCodeExporter]

*MUCH* better!

The long sequence of space characters does still have an issue, but I can't see 
where
I would care unless I was trying to enter some weird ascii-art.  And, as soon 
as I
type a text character, it jumps to the right place.  The remaining weirdness is 
way a
low priority now.

The stylesheet is better, too, it picks a font that looks more like what I would
expect, say, xterm to pick.  Might be nice if the right click menu had some font
options, actually, like ctrl-right on xterm.

The big issue for me was when I was typing text and progressively the cursor 
went
weird, now that doesn't seem to happen at all vertically or horizontally.

Since the cursor is able to locate correctly when text is entered, is it 
something
where a millisecond introduction and removal of a '.' or even an   would locate
it?  Never mind, I shouldn't make guesses when I haven't bothered to read the 
code...

I guess I'm going to have to get comfortable with Ajax at some point, I'm a Java
developer and comfortable with C, but I mostly avoid ECMAScript, I've even 
loaned out
my Javascript and Ajax books to another developer trying to do RDD (Resume 
Driven
Development).  But this kind of thing is cool, if you can do this, all kinds of 
ideas
spring to mind...

Thanks!

Original comment by TomOeh...@gmail.com on 21 Mar 2009 at 4:21

[GoogleCodeExporter]

The latest SVN version (revision 85) has a modified algorithm for cursor 
positioning that should address horizontal positioning at the end of a sequence 
of 
spaces. As I don't actually see the problem myself, I cannot verify the fix. 
But 
since you seemed overall happy with how the code was already working, I am 
closing 
the bug for now. Feel free to re-open if you think the issue is not addresses 
properly.

Original comment by zod...@gmail.com on 21 Mar 2009 at 4:50

• Changed state: Fixed