Browser resize corrupts screen on http://demos.anyterm.org/shellinabox_nano/

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Use Chrome v4
2. Goto http://demos.anyterm.org/shellinabox_nano/
3. Resize browser window.

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

I expect the editor controls and screen layout to adjust to a change in the 
terminal size.

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

The one on the anyterm site.

Please provide any additional information below.

This problem may well be due to anyterm running an old version.  I will 
test it myself and update this bug in a few days.

Original issue reported on code.google.com by cms...@gmail.com on 8 Mar 2010 at 1:12

[GoogleCodeExporter]

Browser resizes seem to be implement in a somewhat awkward way. It looks as if 
they are really just a CSS transformation applied to the entire page. This 
approach breaks some of the size relationships between DOM elements.

I am not sure whether this is a browser bug or a bug in ShellInABox. But in 
either case, it probably needs some tweaks in ShellInABox to deal with resizes. 
And these tweaks might very well have to be different for each browser. For the 
time being, I suggest not to do any resizing.

Original comment by zod...@gmail.com on 2 Sep 2010 at 11:37

• Changed state: Accepted

[GoogleCodeExporter]

Issue 63 has been merged into this issue.

Original comment by zod...@gmail.com on 2 Sep 2010 at 11:37

[GoogleCodeExporter]

Issue 86 has been merged into this issue.

Original comment by zod...@gmail.com on 2 Sep 2010 at 11:39

[GoogleCodeExporter]

Can you check if this problem still exists? I just made a few changes that 
affected this code.

Original comment by zod...@gmail.com on 3 Sep 2010 at 6:03

[GoogleCodeExporter]

Thanks for looking at this.  It doesn't seem to be fixed.

I've checked out and built the latest source.  (I had not previously installed 
shellinabox.)

Using vi to edit a document, and resizing the window is fine.

Using nano to edit a document, and resizing the window results in screen 
corruption.

Using nano directly (i.e. in an xterm) does NOT produce this corruption.

svn info:

Path: .
URL: http://shellinabox.googlecode.com/svn/trunk
Repository Root: http://shellinabox.googlecode.com/svn
Repository UUID: 0da03de8-d603-11dd-86c2-0f8696b7b6f9
Revision: 221
Node Kind: directory
Schedule: normal
Last Changed Author: zodiac@gmail.com
Last Changed Rev: 221
Last Changed Date: 2010-09-04 18:50:11 +0100 (Sat, 04 Sep 2010)

command line (as root):

./shellinaboxd --port=8888 -d --disable-ssl

then, once logged in:

nano mydoc.txt

Thanks,

Chris.

Original comment by cms...@gmail.com on 6 Sep 2010 at 5:13

[GoogleCodeExporter]

Here are some screen shots.

siab_nano_corrupt.png shows the problem.  xterm_nano_no_corruption.png shows 
that nano works correctly in xterm, which leads me to believe that it may an 
issue with shellinabox.

Let me know if I can provide any more information.

All the best,

Chris.

Original comment by cms...@gmail.com on 6 Sep 2010 at 5:23

Attachments:

• siab_nano_before.png
• siab_nano_corrupt.png
• xterm_nano.png
• xterm_nano_no_corruption.png

[GoogleCodeExporter]

Thank you for the screen shots. This helps understand the bug that you are 
reporting. I thought, you were reporting that changing the font size (with 
CTRL-+ and CTRL--) resulted in corruption. That's something I had addressed 
with recent changes.

Your problem is apparently different. You are seeing corruption when you are 
resizing the browser's window with the mouse.

This is a little more mysterious. I haven't touched this code in a good while, 
and it has been working fine for me regardless of the browser and regardless of 
the application that I run inside the terminal.

It looks as if "nano" is never being informed of the new terminal dimensions. I 
know that some Linux kernels had bugs with reporting this information, but I 
thought that was fixed long ago.

Can you do a little experiment for me? Run the following command in your shell:

while :; do i=$(stty -a | awk 'NR == 1 { print ($7+0) "x" ($5+0) }'); [ "$i" != 
"$j" ] && { j="$i"; echo "$i"; }; done

Now resize the browser window and check whether the information that the shell 
prints matches the terminal dimension that ShellInABox displays for you.

Original comment by zod...@gmail.com on 6 Sep 2010 at 4:26

[GoogleCodeExporter]

I tried the command, but unfortunately it works perfectly, always matching what 
ShellInABox reported after a resize.

I can confirm the corruption also happens in Firefox (3.6.8).

I tried one of the ncurses example programs (rain.c), to see if the problem was 
restricted to nano.  rain.c also displays corruption.  Like nano it does not 
recognise terminal resizing.  It works fine when it is run in an xterm window 
and resized.

Could it be that ncurses uses a different method of determining terminal size?  
rain.c has ROWS and COLS (macros?) which change at runtime when an xwindow is 
resized, but not when ShellInABox is resized.  (vi also uses ncurses, but 
doesn't have the resizing problem - confusing.)

All the best,

Chris.

Original comment by cms...@gmail.com on 6 Sep 2010 at 8:39

Attachments:

• rain.c.png

[GoogleCodeExporter]

There really is only one way that the terminal size can be signaled. On Linux, 
this always just involves calling "ioctl(pty, TIOCSWINSZ, ...)".

A quick web search does show, that there used to be a kernel bug a little while 
ago. Sometimes, the kernel would race and report that the window size has 
changed before it actually set the correct values: 
http://fixunix.com/kernel/519209-patch-tty_io-fix-tiocswinsz-tiocgwinsz-races.ht
ml

What kernel version are you running? Maybe, upgrading to a recent kernel would 
fix things for you?

It certainly all looks as if this is a timing-related problem. And 
unfortunately, ShellInABox seems to be really good in triggering the problem 
for you.

Actually, there is one other thing you could try. Looking through the xterm 
sources, it has a comment that says "signal(SIGTTOU, SIG_IGN)" is needed to 
make changing of window sizes work correctly. I don't believe that statement is 
true, but you could try adding this line at the beginning of main() and see if 
it makes any difference. I seriously doubt it, though.

Original comment by zod...@gmail.com on 6 Sep 2010 at 9:12

[GoogleCodeExporter]

Hi, I've only just realised that you may not have been able to reproduce the 
problem.  

The original link http://demos.anyterm.org/shellinabox_nano/ shows this 
corruption, irrespective of whether I use firefox or chrome on (linux or 
windows) or IE on windows. 

I have tried two different linux kernels, (when running a server myself):
Linux chris-linux-desktop 2.6.32-24-generic #42-Ubuntu SMP Fri Aug 20 14:21:58 
UTC 2010 x86_64 GNU/Linux
and
Linux ns0 2.6.27-17-server #1 SMP Fri Mar 12 04:04:33 UTC 2010 i686 GNU/Linux

This seems to rule out kernel-version/AMD64 issues.  It could be a Ubuntu issue 
(I don't know what the people at anyterm are running).

Could you see if you can replicate the issue?  You just need to follow the 
anyterm link, and resize your browser window.

Thanks,

Chris.

Original comment by cms...@gmail.com on 7 Sep 2010 at 11:40

[GoogleCodeExporter]

Just back from holiday.  If there's anything I can do to help you reproduce and 
fix this bug, just let me know.

All the best,

Chris.

Original comment by cms...@gmail.com on 20 Sep 2010 at 10:37

[GoogleCodeExporter]

I see this bug when using the utility "htop" on debian with shellinabox 2.10-1 
and thought id share something that might be useful. While "htop" is 
unresponsive to screen resizes "sudo -u my_username -i htop" works fine.

Original comment by Sean....@gmail.com on 9 Dec 2011 at 3:30

[GoogleCodeExporter]

while messing with it I figured out if you run the commands "unset LINES" and 
"unset COLUMNS" everything works fine. i have added these 2 commands into my 
.bashrc file and now everything always resizes properly, so theres an easy 
work-around for it at least :). in a normal shell session these variables are 
undefined from the start IIRC.

Original comment by Sean....@gmail.com on 15 Dec 2011 at 9:06

[GoogleCodeExporter]

Took a look at the code and commenting out the IF statement lines 1268-1274 in 
launcher.c corrects the problem, however Im not sure if it breaks anything else 
so i will be sticking with the bashrc trick for now. (you can apply it to a 
whole system by adding it to "/etc/profile"). This should be a good starting 
point for an actual fix. Is there any reason for $LINES and $COLUMNS to be 
defined in launcher.c?

Original comment by Sean....@gmail.com on 15 Dec 2011 at 11:03

[GoogleCodeExporter]

to be more specific, heres the change for 2.14:

diff --git a/shellinabox/launcher.c b/shellinabox/launcher.c.patched
index 68d8862..50f8070 100644
--- a/shellinabox/launcher.c
+++ b/shellinabox/launcher.c.patched
@@ -1457,13 +1457,6 @@ static void childProcess(struct Service *service, int 
width, int height,
   check(environment             = malloc(2*sizeof(char *)));
   int numEnvVars                = 1;
   check(environment[0]          = strdup("TERM=xterm"));
-  if (width > 0 && height > 0) {
-    numEnvVars                 += 2;
-    check(environment           = realloc(environment,
-                                          (numEnvVars + 1)*sizeof(char *)));
-    environment[numEnvVars-2]   = stringPrintf(NULL, "COLUMNS=%d", width);
-    environment[numEnvVars-1]   = stringPrintf(NULL, "LINES=%d", height);
-  }
   for (int i = 0; legalEnv[i]; i++) {
     char *value                 = getenv(legalEnv[i]);
     if (value) {

Original comment by Sean....@gmail.com on 23 Apr 2012 at 4:25

[GoogleCodeExporter]

I can confirm that it is NOT fixed in Chrome 18.0.1025.162 m or Firefox 11.0.

Original comment by cms...@gmail.com on 24 Apr 2012 at 11:09

Attachments:

• chrome-shell-in-a-box.png
• ff-shell-in-a-box.png