Fill up the REPL history so it is forced to scroll. (May I recommend print(string-repeat("\n", 100))?)
Type in a valid expression like 2 + 3. Note that the REPL scrolls so you can see the whole result and the next line of input.
Now try typing in an invalid expression, like 2 + "". Note that the REPL doesn't scroll, so you can only see the top of the error and can't see the next line of input.
Notes on the fix
In the course of debugging, I learned that the scroll() calls are actually not necessary in Chrome, which seems to move scroll position automatically because of something we're doing in creating the new line input and setting focus there.
But in Safari, the scroll() calls are necessary and this one path, for compiler errors, didn't have one.
There's probably a better place to put this, so that the scroll happens automatically after both success, error, and compiler failures. But if so, I couldn't find it. I'm still hazy on the control flow in-between displayResult and repl.runtime.setParam("onTrace", ....
Steps to reproduce
print(string-repeat("\n", 100))?)2 + 3. Note that the REPL scrolls so you can see the whole result and the next line of input.2 + "". Note that the REPL doesn't scroll, so you can only see the top of the error and can't see the next line of input.Notes on the fix
scroll()calls are actually not necessary in Chrome, which seems to move scroll position automatically because of something we're doing in creating the new line input and setting focus there.scroll()calls are necessary and this one path, for compiler errors, didn't have one.scrollhappens automatically after both success, error, and compiler failures. But if so, I couldn't find it. I'm still hazy on the control flow in-betweendisplayResultandrepl.runtime.setParam("onTrace", ....