Steps to Reproduce:
Are you scrolling using mouse/trackpad? Can you try ctrl+shift+arrow/page up/page down (or whatever the OS X equivalent is).
@wallverb is right. Their points are all correct.
I have experienced this. However, I am able to scroll with the trackpad if I place the cursor over the left side of the terminal (where my content is). If I move the cursor too far to the right, I cannot scroll.
Maybe the scrollable element is assuming the minimum width necessary to contain the terminal text, rather than occupying the full width of the terminal.
@masonicboom that is expected on stable, on the insiders build scrolling _should_ be working as expected.
I can't reproduce on Insiders, two finger trackpad scroll seems to work just fine? OS X Yosemite 10.10.5 on a 2014 MacBook Pro.
@Tyriar let me know if I can help somehow to troubleshoot this issue, still not working for me Version 1.3.0-insider (1.3.0-insider) de66522e06d74752d48d92e934dcd026050355ba OS X 10.11.15 - 2012 Macbook Pro
@wallverb would you be able to pull down https://github.com/sourcelair/xterm.js and check if you can reproduce on the demo?
@Tyriar pulled down and started demo - scrolling works fine, let me know what to do next :)
Found the difference, in xterm.js around lines 1132-1136 in this piece of code:
// allow mousewheel scrolling in
// the shell for example
on(el, wheelEvent, function(ev) {
if (self.mouseEvents) return;
if (self.applicationKeypad) return;
if (ev.type === 'DOMMouseScroll') {
self.scrollDisp(ev.detail < 0 ? -1 : 1);
} else {
self.scrollDisp(ev.wheelDeltaY > 0 ? -1 : 1);
}
return self.cancel(ev);
});
In vscode self.applicationKeypad is true that's why it's returning while xterm.js demo has this value set to false
The reason why it's set to true is due to this flow:
internal/child_process.js line 444:
handleMessage(target, message, undefined); where message={type: 'data', content: "[K[?1h="}
which then calls:
terminalInstance.ts line 47
this.xterm.write(message.content);
which then does:
xterm.js line 1722
// ESC = Application Keypad (DECPAM).
case '=':
this.log('Serial port requested application keypad.');
this.applicationKeypad = true;
this.state = normal;
break;
I hope it helps
One update: seems like xterm demo is starting with bash, while vscode starts with my zsh (https://github.com/robbyrussell/oh-my-zsh)
Interesting... Can you check what message.content is in this case? Whatever it is, it seems to be telling xterm to enter the application keypad mode.
Message content is:
[0m[27m[24m[J[01;32m➜ [36msolution[00m [K
and
[?1h=
which renders it as:

It's definitely related to zsh if i set "terminal.integrated.shell.osx": "/bin/bash" then its ok, but if its "terminal.integrated.shell.osx": "/bin/zsh" then it does not scroll due to = character in [?1h=
Submitted bug at xterm.js repo: https://github.com/sourcelair/xterm.js/issues/151
For time being commenting out line zle -N zle-line-init in ~/.oh-my-zsh/lib/key-bindings.zsh fixes the scroll issue
Thanks for investigating this @wallverb! :+1:
I am facing scrolling issues in ubuntu 14.04,VSCode version 1.2.1.On scrolling up the text in the console goes far left sometimes(on using ctrl+shift+PgUp) and invisible at other times(on using trackpad).
@niwsa those should be fixed in the upcoming v1.3.0, This issue is about scrolling not working at all using the trackpad.
also not work in ubuntu:
Distributor ID: Ubuntu
Description: Ubuntu 16.04 LTS
Release: 16.04
Codename: xenial
and vscode:
Visual Studio Code v1.3.0
@arastu there is a bug in 1.3.0 that if you resize the terminal window you can no longer scroll in that area, unfortunately it snuck into the library we use just before the release. Does it work all the time if you scroll with the cursor on the left side of the terminal?
@wallverb I think this is specific to oh my zsh, or at least a zsh that is printing an = character. In my oh my zsh theme I also have an = character, but without oh my zsh I do not and scrolling is working. Is there anyway to filter out that character and still have it work?
@richarddavenport just tried on my macbook and zsh works fine, I'll update the title accordingly. Since this is an upstream issue, let's centralize discussions in https://github.com/sourcelair/xterm.js/issues/151
@Tyriar @wallverb I opened an issue with oh my zsh and found there is a fix for this issue. I'm running with this branch right now, and scrolling is working!
The fix I had was setting the "width" CSS styling property of the "monoco-scrollable-element" to 100%. This immediately completely fixed the issue. This DIV was located as a child element of the "workbench.panel.terminal".
@ext0 FYI that element was removed either in 1.3.0 or in the upcoming 1.4.0.
@Tyriar Ah gotchya, I haven't updated yet. Good to know!
I am also facing same issue on Windows 10 with VS Code V1.4.0. Ctrl+shift+up/down also not working.
@technbuzz this is to do with oh-my-zsh, ctrl+up/down should scroll the terminal on Windows in the latest Insiders build.
Same issue on MAC. Please fix, it's really annoying :(.
@drptbl The issue is open for OS X, as stated in the opening comment. It's also an upstream issue, meaning that there are other projects that need to be fixed before this one can be fixed. Here's a workaround.
It's really annoying!!!
This should be fixed in the next insiders build.
I'm having the same problem with zhs and bash. Most of the time it scrolls, sometimes it doesn't!
VSC 1.15.1
@StefanoChiodino please create a new issue with more details
Most helpful comment
Submitted bug at xterm.js repo: https://github.com/sourcelair/xterm.js/issues/151
For time being commenting out line
zle -N zle-line-initin~/.oh-my-zsh/lib/key-bindings.zshfixes the scroll issue