Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow disabling any and all automatic scrolling or collapsing of on-screen content #7317

Open
2 tasks done
burnpanck opened this issue Apr 9, 2024 · 3 comments
Open
2 tasks done

Comments

@burnpanck
Copy link

burnpanck commented Apr 9, 2024

  • I checked to make sure that this issue has not already been filed
  • I'm reporting the issue to the correct repository: Maybe, maybe not. For the best I try, I seem to have 50 % odds at hitting the right repo among notebook/jupyterlab.

Problem

When working interactively, screen jerk is major UX pain. If you let a long-running notebook run in the background, it may indeed be beneficial if it directs you to some well-thought point of interest when you come back to the window, but while I am actively working with a notebook, any movement on screen that I did not actively command is just disorienting. Of course, if output is being generated within the view that I see, then some parts will have to move, and it's a design question which parts should stay still. But as long as input cells or append-only output is on screen, there is at least one reasonable choice of what part should not move.

In the last year or so (somewhere between the move to the jupyterlab backend / notebook v7 and now), I feel that this part of UX has considerably deteriorated. In fact, there are so many issues related to that in the two repos, combined with a wealth of outdated information related to pre v7 notebook, that I find it hard to figure out where and what to look and/or report, or what is intended behaviour in the first place.

From my perspective, it feels like there are some half-baked features in current versions of notebook that seriously hurt user-experience, and I wish there was a way to just dumb it down / disable all of that.

Proposed Solution

  • Identify and document what the set of intended features related to scroll and collapse are
  • Provide an option to disable any and all scroll - this would allow me to clearly open a bug-report against that feature whenever I encounter UI jerk.
@burnpanck burnpanck added enhancement status:Needs Triage Applied to issues that need triage labels Apr 9, 2024
@RRosio
Copy link
Collaborator

RRosio commented Apr 16, 2024

Thank you for opening this issue @burnpanck. We noticed you filed an issue related to this in JupyterLab, jupyterlab/jupyterlab#15968. Are you looking for all outputs to scroll when they reach a certain length? I could not find a documented expectation for this behavior, would you be able to provide more information on what that may look like?

@RRosio RRosio added status:Needs Discussion and removed status:Needs Triage Applied to issues that need triage labels Apr 16, 2024
@RRosio
Copy link
Collaborator

RRosio commented Apr 16, 2024

For context, you can also try Visual Studio code, https://code.visualstudio.com/docs/datascience/jupyter-notebooks, is the default scrolling behavior there more like what you would expect? (thanks @JasonWeill)

@burnpanck
Copy link
Author

burnpanck commented Apr 17, 2024

Are you looking for all outputs to scroll when they reach a certain length?

No. If at all, I'd be looking for the converse; no automatic collapse at least while on-screen, to prevent UI jerk. Indeed, the behaviour of automatic output collapse in jupyter notebook 7 is also worse than before, I filed issues in that regard too: #7003. However, here, I was more concerned with the movement of input cells on-screen. Output collapse plays into this by changing the spacing of surrounding input cells, so if it happens on-screen, it will have to move at least one input cell. This particular case cannot be fully avoided though, because even if the output cell does not collapse, it may grow as output is being generated. But it should always be possible to keep at least part of what is visible on-screen non-moving.

I would rather not switch my workflow to Visual Studio Code, just because of erratic scroll in the browser. Again: The desired behaviour is very simple: The notebook should not scroll on it's own, period. It appears to me that jupyter lab / jupyter notebook introduced new behaviours intended to provide a better UX, but IMHO, it's become worse. Because these are clearly "features" (it's not a browser default behaviour, but something explicitly implemented in jupyter), I assume it is conceivable to disable them.

You are right that I did log an issue about one particularly annoying case of erratic scroll (jupyterlab/jupyterlab#15968), in that case it is clearly a bug. However, I also noticed for example that the notebook automatically scrolls when I enter a command in the python debugger (%debug magic) in the jupyter notebook. The behaviour I observed there may arguably be considered "as intended" - I still find it disorienting. Rather than trying to start a discussion about every single case of intended vs unintended and useful vs. annoying automatic scroll, this specific feature request here is to indicate that some people find screen jerk disorienting while others may potentially find it useful. A configuration option that does not address specific features, but addresses the screen jerk would cater to us.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants