Hyper: Lowest row of the shell extends beyond viewport

[willricketts]

Issue

The lowest row of the shell extends beyond the bottom of the viewport in some cases, preventing the user from seeing their input.

Reproduction Steps

The issue seems to be intermittent, and I can't seem to pin down exactly what actions could be causing it.
-
Hyper 1.4.8
Electron 1.7.8
win32 x64 10.0.16299

[shaneknysh]

This seems to be caused by the default padding setting.

Setting bottom padding to 0 allows you to see the last row of output and input but it is not visually pleasing as the last row is partially cut off.

[albinekb]

@shaneknysh are you seeing this in 2.0 too?

[shaneknysh]

I was seeing it last night. (I just re-installed hyper).

I was constantly having to use clear/cls because I would not be able to see the entry point after a long output. I set my padding to
padding: '12px 14px 0 14px'
and it was fixed.

I can not reproduce it today. I set the padding back to default to grab a screen shot and the bottom line is always visible. I'll try to reproduce it and report if I can get it to happen again.

my plugins are
plugins: ["hyper-monochrome", "hyper-vsplit-fix", "hyperterm-tabs"]
disabling them does not re-introduce the issue.

[inside]

Hi, please have a look at this screenshot:

Is it this you guys are talking about?

I suspect the .term_fit class from the divs surrounding xterm.js. I played with the .term_fit's height but couldn't remove the unwanted spaces and got bad layout side effects: the term is overflowing outside of the main window. Help appreciated, thanks!

EDIT: I forgot to mention I have padding: '0' in the config.

EDIT 2: Guys, the .term_fit class is fine. It's more about how xtem.js or any other term works:
a terminal window consists of n cells spreaded accross cols and rows (like a checkboard). The window could be resized by the cell's width and height and not by pixels like it's done in gnome-terminal. What do you think?

Hyper 2.1.0-canary.1-2968
process.versions.electron: 1.8.4
Ubuntu 16.04

[cfjedimaster]

I'm seeing this as well in Windows.

[suksit]

^
This happens every time I created a new tab. It's like the "display area" got pushed down by the newly created tab bar.

[cfjedimaster]

@suksit oh that is a great point - it is on new tabs only and I bet you are exactly right.

[inside]

I can reproduce on new tab.

[chabou]

@suksit nice clue. We should try to inspect this more precisely.

[webcoderkz]

Any news about this? I have the same issue with 2.0.0 on Windows 10 (1803)

Steps to reproduce:

1. Open Hyper
2. Open 2nd Tab
3. Use git status or something similar command that has a lot of output

Workaround is to switch to previous tab and then switch back.

[jaeseok-park]

Opening the second tab causes this issue. (On Windows 10)
I guess that the tab area push down the viewport.

[shaneknysh]

the issue also disappears if you switch to another tab and then return top the new tab.

[jaeseok-park]

Right.
And if the window is resized, the issue disappears.

[Ayanrocks]

This bug is annoying and is happening on Linux too. Any fix. Even the latest version (2.1.0) doesn't fix it.

[mshindal]

This is still happening, and following the instructions given at https://github.com/zeit/hyper/issues/2654#issuecomment-411638137 will reproduce it every time. Not sure why this issue is marked as "Awaiting Response".

[shaneknysh]

@Stanzilla can the awaiting response tag be removed?