occasional single line window in chrome

[GoogleCodeExporter]

What steps will reproduce the problem?
1. connect normally in google-chrome or chromium browser
2.
3.

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

instead of the full browser window being used by the widget I only get one line 
of text.

restarting the browser does not solve this problem

this problem showed up before, but several days later it cleared and everything 
worked properly for a week or two, then it started agein.

I have not had a similar problem with firefox

What version of the product are you using? On what operating system?
Shell In A Box version 2.10 (revision 186)

Please provide any additional information below.

Original issue reported on code.google.com by david.eu...@gmail.com on 18 Aug 2010 at 7:16

• Merged into: #55

[GoogleCodeExporter]

I don't think I have ever been able to reproduce this problem with Chrome. But 
I vaguely recall that I could sometimes trigger it if I do crazy things in 
Firebug on Firefox. It always seemed to be a result of normal HTML rendering 
and script execution getting disrupted by some third-party component. Do you by 
chance have any Chrome extensions that might be doing strange things? Can you 
temporarily disable all extensions and see if that fixes your problem?

Original comment by zod...@gmail.com on 18 Aug 2010 at 7:22

[GoogleCodeExporter]

no extensions at all (If I were using them more extensively I would use 
noscript, but since I'm only using them to access this, I don't have any 
extensions installed)

Original comment by david.eu...@gmail.com on 18 Aug 2010 at 7:32

[GoogleCodeExporter]

Hmm, there goes that theory...

Don't really know where to start, as you are the only person reporting this 
problem and more importantly as I don't know how to reproduce it.

Maybe, you could check if you see any useful output in the JavaScript Console 
(SHIFT-CTRL-J).

Original comment by zod...@gmail.com on 18 Aug 2010 at 8:22

[GoogleCodeExporter]

here is the output in ther terminal window that chromium was started from.

what would I look at in the javascript console?

** (exe:9479): DEBUG: NP_Initialize
** (exe:9479): DEBUG: NP_Initialize succeeded
** (exe:9479): DEBUG: totemPlugin [0x431b7d0]
** (exe:9479): DEBUG: 0x431b7d0: "Init mimetype 'audio/x-wav' mode 1"
** (exe:9479): DEBUG: 0x431b7d0: "Document URI is 'https://sitename/shell/'"
** (exe:9479): DEBUG: 0x431b7d0: "Base URI is 'https://sitename/shell/'"
** (exe:9479): DEBUG: 0x431b7d0: "Real mimetype for 'audio/x-wav' is 
'audio/x-wav'"
argv[0] classid clsid:02BF25D5-8C17-4B23-BC80-D3488ABDDC6B
argv[1] id beep_embed
argv[2] src beep.wav
argv[3] autostart false
argv[4] volume 100
argv[5] enablejavascript true
argv[6] type audio/x-wav
argv[7] height 16
argv[8] width 200
argv[9] style position:absolute;left:-1000px;top:-1000px
** (exe:9479): DEBUG: 0x431b7d0: "mSrcURI: beep.wav"
** (exe:9479): DEBUG: 0x431b7d0: "mBaseURI: https://sitename/shell/"
** (exe:9479): DEBUG: 0x431b7d0: "mCache: 0"
** (exe:9479): DEBUG: 0x431b7d0: "mControllerHidden: 0"
** (exe:9479): DEBUG: 0x431b7d0: "mShowStatusbar: 0"
** (exe:9479): DEBUG: 0x431b7d0: "mHidden: 0"
** (exe:9479): DEBUG: 0x431b7d0: "mAudioOnly: 0"
** (exe:9479): DEBUG: 0x431b7d0: "mAutoPlay: 0, mRepeat: 0"
** (exe:9479): DEBUG: 0x431b7d0: "Viewer spawned, PID 9484"
** (exe:9479): DEBUG: 0x431b7d0: "Initial window set, XID 5c0001a size 166x13"
** (exe:9479): DEBUG: 0x431b7d0: "No viewer proxy yet, deferring SetWindow"
** (exe:9479): DEBUG: 0x431b7d0: "GetScriptableNPObject [0x431b7d0]"
** (exe:9479): DEBUG: totemCone [0x43198a0]

Original comment by david.eu...@gmail.com on 27 Aug 2010 at 10:54

[GoogleCodeExporter]

It is very unlikely you'll find any useful information on the text console. 
There is only very limited data that gets logged to that location.

What you should be looking at is the JavaScript console. Click on the "wrench" 
icon, and select "Tools->JavaScript Console". You can also press 
SHIFT-CONTROL-J.

There are lots of useful debugging tools accessible from the console.

Original comment by zod...@gmail.com on 27 Aug 2010 at 11:00

[GoogleCodeExporter]

You wouldn't by chance have tried to scale your browser window by pressing 
CTRL-Plus or CTRL-Minus?

That apparently causes all sorts of problems. I am about to submit a fix for 
the one-line problem, but browser scaling still does strange things to the DOM 
tree.

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

• Changed state: Duplicate

[GoogleCodeExporter]

I don't resize the window after starting it up. It's possible that I did so 
some time in the past, but wouldn't starting from scratch (starting a new 
window and then loading the page) fix anything related to resizing?

Original comment by david.eu...@gmail.com on 2 Sep 2010 at 11:48

[GoogleCodeExporter]

That could very well do it. If I recall correctly, all current versions of 
Chrome attempt to remember the scaling factor that you used in the past. So, if 
you set a non-identity scaling factor some time in the past, it might very well 
still be in effect without you realizing it.

As far as I can tell, scaling is implemented as a CSS transform. And on top of 
setting a non-identity scaling factor, it also sets a non-zero margin for the 
body element.

The latter is what is throwing of the code in ShellInABox. We want to know 
whether we are embedded in a website, or if we are supposed to take over the 
entire window. And if there is a margin, we think that we are embedded and that 
we shouldn't rescale to the full size of the window.

You don't actually want the margin, as it looks wrong for a web application. It 
does look OK for a regular web site (and that's presumably why Chrome sets it). 
So, forcing a zero margin seems to be the correct solution.

Original comment by zod...@gmail.com on 3 Sep 2010 at 12:47

[GoogleCodeExporter]

Hello,
I have the same problem. Any solution ? I can provide now information, as I can 
reproduce the problem with my Win 7 + Chrome Version 26.0.1410.64 m.
I really would like to help :)
Br,
 Peter.

Original comment by marc...@demonkutya.com on 21 May 2013 at 5:26

[GoogleCodeExporter]

I see this problem as well in Win 7 64 bit and IE9 (also 64bit)

Original comment by Colin....@gmail.com on 14 Feb 2014 at 2:57

[GoogleCodeExporter]

Also seeing this problem on Chrome with Win 7 32 bit. I've experienced the same 
thing on Chrome and Safari on an iPad with iOS 7.

Original comment by andrete...@gmail.com on 27 Feb 2014 at 11:50

[GoogleCodeExporter]

From what I'm seeing on the chrome inspector, apparently div#scrollable 
sometimes initiates with style="height: 18px" on the element, as opposed to the 
638px or so it usually has.

Original comment by andrete...@gmail.com on 27 Feb 2014 at 11:52

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

the same with my Chrome, everytime I need to change height of div#scrollable 
with "chrome inspector"
it's definitely Chrome "page zoom" problem
For me problem is only on zooom=110%, when I change it to 100% or 125% and 
refresh page it's no longer one line.

Original comment by pkas...@gmail.com on 23 Apr 2014 at 12:19

[GoogleCodeExporter]

I had the same problem.
It was caused by a chrome extensions, "cellect".

http://nottheoilrig.com/cellect/

After disabling it, the problem went away.

Original comment by carsten....@gmail.com on 3 Sep 2014 at 9:54