improve console autoscrolling

[pfitzseb]

Fixes #66.

This is only mostly correct, as the resize listener (@resizer) can only be removed on item insertion, so if you scroll up a bit and then change some item's height (expand a tree for example), the console will still auto scroll to the bottom.

[carocad]

This works on my proto-repl.

Nice job :)

[jasongilman]

@carocad Does it solve the whole problem in Proto REPL or do you think there's still an issue with showing the command that ran?

[carocad]

@jasongilman this sucessfully solved the issue on my proto-repl development version. Both sending the command from an editor and evaluating it directly from the console shift scroll the console to the bottom.

One little issue, though, is that if the user scrolls up and evaluates a command from the editor then it doesn't scroll to the bottom. I guess this is due to the console being fix on the current user view. Not fully sure if that's a bug or not.

[jasongilman]

I think that would be the desired behavior for the console. It works like a normal terminal where it locks to the bottom of output until a user scrolls up and stays that way until scrolling back to the bottom.

On Aug 15, 2016, at 7:20 PM, Camilo Roca notifications@github.com wrote:

@jasongilman this sucessfully solved the issue on my proto-repl development version. Both sending the command from an editor and evaluating it directly from the console shift scroll the console to the bottom.

One little issue, though, is that if the user scrolls up and evaluates a command from the editor then it doesn't scroll to the bottom. I guess this is due to the console being fix on the current user view. Not fully sure if that's a bug or not.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[pfitzseb]

Yeah, that's the intended behaviour.

[pfitzseb]

Any objections to merging this, @MikeInnes?

[MikeInnes]

Looks good. How much is element-resize-detector really doing for us? Could we just call the native dom method easily?

[pfitzseb]

The problem is that there's no native dom method for detecting changes in element size, hence the large number of libraries (>3 ;)) that implement them. This one seems to be one of the more performant and lightweight approaches.

And we need to detect changes in the height of @items simply because we can't know what elements are in there and how they change size -- text-editors are a good example of this, because they change their size arbitrarily on user input.

[MikeInnes]

Fair enough, but I guess I don't feel totally convinced that we need this for arbitrary changes. If I'm expanding a result then having the console move under me may be more annoying than helpful. And if we have finite cases (new cell + change to bottom-most editor) then we can just listen for those and apply the lock as before.

But I've been wrong before. Let's try this out for now and we can see how it feels.

[MikeInnes]

Oh and thanks for doing this as always :D

[pfitzseb]

If we only want to observe a few specific cases, then using a MutationObserver should work pretty well (dropping this here just so no one has to look for it again).

That said, I've really come to like this change -- I always found it so annoying that I couldn't see the complete error when expanding it and have to scroll down. Sure, now the clickable part moves and I have to move the cursor to collapse the result again, but eh... not as bad imho.

[MikeInnes]

There's another issue there which is that errors are displayed with the most relevant info at the bottom. We may want to reverse the stack trace and take some other inspiration from here at some point.